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The  Coast  Guard's  software  architecture  does  not  meet  the  organization's 
needs  for  information  sharing  or  command  and  control.  The  Commandant  of  the 
Coast  Guard  recently  mandated  the  implementation  of  a  Service  Oriented 
Architecture  (SOA)  to  address  this  problem.  This  thesis  describes  a  Service 
Oriented  Architecture  for  Coast  Guard  Command  and  Control  that  integrates 
legacy  applications  and  provides  new  capabilities.  Traditional  software 
architecture  descriptions  make  it  difficult  to  identify  and  understand  the  trade-offs 
between  quality  attributes  that  are  inherent  in  the  design.  We  clarify  these  critical 
issues  by  using  multiple  scenarios  and  use  cases,  in  addition  to  diagrams  and 
functionality  requirements.  Defining  the  architecture  in  this  manner  enables  an 
auditor  to  determine  the  architecture's  validity.  The  Coast  Guard  also  needs  a 
plan  to  implement  this  SOA.  This  thesis  defines  a  process  that  will  deliver  value 
in  the  form  of  usable  capabilities  in  an  incremental  manner.  It  recognizes  the 
constantly  changing  nature  of  both  the  problem  and  the  necessary  solution,  and 
evolves  accordingly.  It  continually  plans  for,  adapts  to,  and  exploits  predictable 
advances  in  technology  to  deliver  more  value.  The  iterative  method  we  propose 
includes  cyclical  evaluation  of  the  system  requirements,  architecture,  and 
implementation  to  provide  continuous  improvement. 
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I.  INTRODUCTION 


A.  BACKGROUND 

The  roles  and  missions  of  the  United  States  Coast  Guard  have  changed 
significantly  from  the  vision  of  its  founding  father,  Alexander  Hamilton,  who  stated 
that  “A  few  armed  vessels,  judiciously  stationed  at  the  entrances  of  our  ports, 
might  at  a  small  expense  be  made  useful  sentinels  of  the  laws.”  (Hamilton  1787) 
Today’s  Coast  Guard  is  a  dynamic,  multi-mission  maritime  organization 
dedicated  to  protecting  the  lives,  safety,  and  security  of  the  American  people. 
This  service  is  a  unique  combination  of  military  combatant,  law  enforcement 
authority,  and  humanitarian  do-gooder  that  the  government  and  American  public 
have  come  to  expect  will  always  be  “Semper  Paratus.”  As  such,  it  has  been 
assigned  a  diverse  set  of  strategic  goals  and  missions  that  require  partnership 
and  interoperability  with  many  local,  state,  federal,  and  international  agencies,  as 
well  as  the  maritime  industry  and  foreign  governments.  The  five  strategic  goals 
and  twenty  major  missions  of  the  United  States  Coast  Guard  are: 

Maritime  Safety  -  Eliminate  deaths,  injuries,  and  property  damage 
associated  with  maritime  transportation,  fishing,  and  recreational  boating.  The 
specific  missions  are  Search  and  Rescue  (SAR),  Marine  Safety  Program, 
Recreational  Boating  Safety,  and  the  International  Ice  Patrol. 

National  Defense  -  Defend  the  nation  as  one  of  the  five  U.S.  armed 
services.  The  specific  missions  include  Defense  Readiness,  Homeland  Security, 
Ports  Waterways  and  Coastal  Security,  and  Polar  Icebreaking. 

Maritime  Security  -  Protect  America's  maritime  borders  from  all  intrusions 
by:  (a)  halting  the  flow  of  illegal  drugs,  aliens,  and  contraband  into  the  United 
States  through  maritime  routes;  (b)  preventing  illegal  fishing;  and  (c)  suppressing 
violations  of  federal  law  in  the  maritime  arena.  The  specific  missions  are  Illegal 
Drug  Interdiction,  Migrant  Interdiction,  Living  Marine  Resource  Protection, 
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General  Maritime  Law  Enforcement,  Exclusive  Economic  Zone  Enforcement,  and 
Treaty  Enforcement. 

Maritime  Mobility  -  Facilitate  maritime  commerce  and  eliminate 
interruptions  and  impediments  to  the  efficient  and  economical  movement  of 
goods  and  people,  while  maximizing  recreational  access  to  and  enjoyment  of  the 
water.  The  specific  missions  are  Aids  to  Navigation,  Icebreaking  Operations,  and 
Vessel  Traffic/Waterways  Management. 

Protection  of  Natural  Resources  -  Eliminate  environmental  damage  and 
the  degradation  of  natural  resources  associated  with  maritime  transportation, 
fishing,  and  recreational  boating.  The  specific  missions  include  Marine 
Environmental  Science,  Foreign  Vessel  Inspections,  and  Marine  Pollution 
Response  and  Enforcement.  (“Missions”) 

Coastguardsmen  are  policemen,  sailors,  warriors,  humanitarians, 
regulators,  stewards  of  the  environment,  diplomats,  and  guardians  of  the  coast 
while  performing  those  missions.  ( America’s  Maritime  Guardian  2)  Each  of 
those  duties  has  unique  requirements  for  the  type,  amount,  and  complexity  of 
information  that  must  be  managed.  This  information  diversity  is  plainly  visible 
when  one  considers  the  list  of  activities  and  accomplishments  during  an  “average 
Coast  Guard  day.” 

Every  day  the  U.S.  Coast  Guard: 

•  Conducts  82  search  and  rescue  cases 

•  Saves  15  lives 

•  Assists  1 14  people  in  distress 

•  Protects  $4.9  million  in  property 

•  Boards  202  vessels  of  law  enforcement  interest 

•  Interdicts  26  illegal  migrants  at  sea 

•  Seizes  $12.4  million  worth  of  illegal  drugs 
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•  Conducts  23  waterfront  facility  safety  or  security  inspections 

•  Enforces  129  security  zones 

•  Monitors  the  transit  of  2,557  commercial  ships  through  U.S.  ports 

•  Boards  1 22  large  vessels  for  port  safety  checks 

•  Boards  4  “high  interest”  vessels 

•  Investigates  20  vessel  casualties  involving  collisions,  allisions  and 
groundings 

•  Responds  to  1 1  oil  and  hazardous  chemical  spills 

•  Conducts  317  vessel  safety  checks 

•  Teaches  63  boating  safety  courses 

•  Conducts  19  commercial  fishing  vessel  safety  exams 

•  Processes  280  mariner  licenses  and  documents 

•  Services  140  aids  to  navigation 
(“Average  Day”) 

With  such  a  high  volume  of  daily  activity  in  so  many  different  mission 
areas,  the  Coast  Guard  faces  a  daunting  information  and  communication 
problem.  It  needs  to  efficiently  process  and  effectively  utilize  large  amounts  of 
varied  information  that  typically  originates  from  unplanned  events.  Unfortunately 
the  Coast  Guard  is  burdened  with  an  information  technology  (IT)  infrastructure 
composed  of  standalone  applications  and  communications  networks  that  lack 
interoperability.  The  combination  of  heterogeneous  missions,  applications,  and 
networks  creates  information  sharing  problems  within  the  Coast  Guard  and  with 
external  entities  that  result  in  operational  inefficiency  and  ineffectiveness.  In 
addition  the  Coast  Guard  has  become  an  integral  part  of  the  rapidly  evolving, 
extended  homeland  security  enterprise  that  spans  multiple  federal  departments 
and  reaches  out  to  many  state  and  local  government  agencies.  This  means  the 
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information  sharing  needs  of  the  Coast  Guard  are  ever  growing  and  will  be 
increasingly  influenced  by  its  partners,  both  within  the  federal  government  and 
beyond.  The  September  11th  2001  terrorist  attacks  and  Hurricane  Katrina 
highlighted  weaknesses  in  our  nation’s  intra-  and  inter-agency  information 
sharing  and  “demonstrated  the  critical  need  for  developing  improved  (distributed, 
shared  and  fault-tolerant)  enterprise  governance  systems  that  are  at  once  stand¬ 
alone  and  interoperable.”  (Bayne  14)  In  response  to  these  challenges,  the  Coast 
Guard  must  develop  a  credible  architecture  and  then  adopt  a  flexible,  rapid,  and 
incremental  implementation  process. 

B.  SOFTWARE  ARCHITECTURE 

Enterprise  level  software  architectures  connect  business  goals  and 
computer  systems  by  describing  the  structures  of  the  software  elements, 
including  the  externally  visible  properties  of  the  elements,  and  the  relationships 
and  interactions  between  them.  “Externally  visible”  properties  refers  to  those 
assumptions  that  other  elements  can  make  about  the  behavior  of  an  element, 
such  as  its  provided  services  and  performance  characteristics.  The  details  of 
elements  that  have  solely  to  do  with  internal  implementation  are  by  definition  not 
architectural.  The  architecture  provides  the  fundamental  organization  of  the 
system  and  the  principles  that  govern  its  design  and  evolution.  (“Published 
Software  Architecture  Definitions”) 

Successful  software  architectures  are  designed  to  meet  both  functional 
and  quality  attribute  requirements.  The  functional  requirements  define  what  the 
software  components  do,  and  these  are  typically  written  in  brief  scenarios  called 
use  cases.  An  example  of  a  functional  requirement  is:  given  the  necessary  six 
input  parameters  (Commence  Search  Point,  Length,  Width,  Major  Axis,  Track 
Spacing,  First  Turn),  calculate  the  waypoints  for  a  parallel  search  pattern  as 
defined  by  the  National  SAR  Manual  and  output  them  in  Extensible  Markup 
Language  (XML)  format  that  complies  with  the  Joint  Consultation  Command  & 
Control  Information  Exchange  Data  Model  (JC3IEDM)  schema.  Quality  attributes 
are  the  benchmarks  that  describe  a  system’s  intended  behavior  within  the 
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environment  for  which  it  was  built.  They  provide  the  means  for  measuring  the 
fitness  and  suitability  of  a  product.  Quality  attribute  requirements  such  as  those 
for  performance,  security,  modifiability,  reliability,  and  usability  have  a  significant 
influence  on  the  software  architecture  of  a  system.  (“Software  Architecture 
Glossary”) 

1.  Software  Architecture  for  Command  and  Control 

The  Coast  Guard  does  not  have  a  viable  enterprise  level  software 
architecture  that  meets  its  current  needs,  let  alone  its  rapidly  evolving  future 
needs.  It  is  burdened  with  a  collection  of  “stovepipe  systems”  that  were 
individually  created  to  address  specific  functional  needs,  without  consideration 
or  design  for  current  functionality  and  quality-attribute  requirements.  Each 
stovepipe  embeds  the  semantics  of  the  data  and  the  processing  logic  (functions) 
within  the  system.  This  configuration  prevents  other  programs  from  accessing 
either  the  data  or  functions,  effectively  trapping  them  within  the  stovepipe. 
Because  it  is  extremely  difficult  to  integrate  stovepipes,  new  systems  often  repeat 
data  and  functions  which  produces  two  serious  problems.  The  first  problem  is 
that  data  about  the  same  object  (vessel,  report,  etc.)  often  differs  from  one 
stovepipe  to  the  next,  which  creates  confusion  and  uncertainty  for  the  users.  The 
second  problem  is  the  limitation  in  the  number  of  systems  a  human  can 
simultaneously  utilize.  Relevant  data  and  useful  functionality  may  go  unused 
because  they  are  too  difficult  to  access  and  not  all  users  have  access  to  every 
stovepipe.  To  solve  this  problem  the  Coast  Guard  must  integrate  the  data  and 
functionality  from  the  stovepipes  in  an  new  architecture  that  supports  its  rapidly 
evolving  needs. 

This  thesis  will  focus  on  the  development  of  a  software  architecture  for 
Coast  Guard  Command  and  Control.  Coast  Guard  Publication  1  defines 
Command  and  Control  as  “the  exercise  of  authority  and  direction  by  a  properly 
designated  commander  over  assigned  and  attached  forces  in  the 
accomplishment  of  the  mission.”  This  includes  planning,  directing,  coordinating, 
and  controlling  forces  and  operations  to  accomplish  the  mission.  ( America’s 
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Maritime  Guardian  60)  Many  theories  about  command  and  control  break  the 
decision  making  process  into  sense-decide-act  stages  that  form  an  iterative  loop. 
Dr.  Rick  Hayes-Roth  further  refines  this  theory  by  defining  efficient  thought  by 
intelligent  beings  (person,  organization,  system).  The  functions  of  efficient 
thinking  divide  into  eight  steps,  each  supported  by  a  world  model  that  represents 
the  intelligent  being’s  understanding  of  how  things  work.  “The  world  model 
provides  the  knowledge  that  an  intelligent  being  uses  to  interpret  events, 
generate  candidate  plans  for  improving  situations,  and  select  the  most  attractive 
candidates  for  execution.”  (Hayes-Roth,  Hyper-beings  58) 
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The  eight  steps  of  efficient  thought  are  numbered  in  a  typical  sequence, 
though  in  most  complex  organizations  all  eight  steps  operate  in  parallel.  “The 
intelligent  being  (1)  observes  what’s  happening  in  the  environment,  (2)  assesses 
the  situation  for  significant  threats  and  opportunities,  (3)  determines  what 
changes  are  desirable,  (4)  generates  candidate  plans  for  making  those  changes, 
(5)  projects  the  likely  outcomes  of  those  plans,  (6)  selects  the  best  plan,  and  (7) 
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communicates  that  plan  to  key  parties  and  implements  it.  Throughout,  the 
intelligent  being  (8)  validates  and  improves  its  model.  The  model  supports  all 
eight  activities,  although  only  steps  1,  2,  7  and  8  directly  update  and  modify  the 
model.”  (Hayes-Roth  Hyper-beings  59)  Software  architecture  for  command  and 
control  needs  to  support  the  use  of  these  eight  steps. 

2.  Coast  Guard  Command  and  Control  Architecture 

The  Coast  Guard  Command  Center  Program  Manual  (CCPM)  describes  a 
system  model  that  depicts  the  fundamental  components  of  command  center 
performance  as  seven  capabilities  that  produce  three  outputs.  This  system 
model  relies  upon  the  interaction  between  the  capabilities  of  planning,  execution, 
information  collection,  information  processing,  information  sharing,  awareness, 
and  assessment  to  produce  information  management,  situational  awareness, 
and  command  and  control.  While  not  identical,  many  similarities  exist  between 
the  Coast  Guard’s  model  and  Dr.  Hayes-Roth’s  efficient  thought  process 
described  above. 


Figure  2. 


Coast  Guard  Command  Center  System  Model  (From:  Command 
Center  Program  Manual  Figure  1  -2-1 ) 


7 


The  authors  of  the  CCPM  use  a  triangle  of  triangles  to  represent  each  of 
the  seven  capabilities  in  the  system  model.  Each  “capability”  triangle  is 
composed  of  three  smaller  triangles;  a  blue  one  representing  agents  (human  and 
software)  to  perform  tasks,  a  green  one  representing  infrastructure  (computers, 
sensors,  etc.),  and  a  red  one  representing  doctrine.  The  manual  lists  35  different 
stovepipe  software  applications  watchstanders  can  use  to  perform  their  duties. 
However,  the  system  model  does  not  describe  how  these  elements  function  and 
interact  to  produce  the  required  outputs.  Absent  this  critical  analysis  and 
documentation,  the  current  system  model  will  never  reliably  produce  the  desired 
results. 

Clearly  the  Coast  Guard  needs  to  find  new  and  better  ways  of  managing 
information  and  providing  capabilities  in  response  to  quickly  changing  needs.  It 
needs  to  design  a  component-based  architecture  that  provides  the  necessary 
functionality  with  the  required  quality  attributes.  The  Coast  Guard  will  always 
have  limited  resources  and  its  command  and  control  requirements  will  continue 
to  change  over  time.  Therefore,  any  new  architecture  must  facilitate  integration 
with  legacy  systems  in  a  way  that  reuses  existing  assets  and  allows  flexible 
reconfiguration  of  both  existing  and  new  assets  as  needed.  The  architecture 
should  also  enable  an  evolution  from  the  current  state  to  required  functionality 
that  delivers  value  at  each  step  along  the  way. 

3.  Service-Oriented  Architecture  (SOA) 

The  Commandant  of  the  Coast  Guard  has  mandated  the  implementation 
of  a  Service-Oriented  Architecture  to  “better  serve  the  needs  of  all  our  internal 
and  external  customers.”  (Allen)  The  SOA  methodology  will  supposedly  enable 
the  Coast  Guard  to  reduce  the  expense  of  integration,  increase  asset  reuse,  and 
increase  business  (organizational)  agility.  SOA  encapsulates  the  distinct 
functions  contained  in  enterprise  applications  into  loosely-coupled,  interoperable, 
standards-based  services  that  interact  via  a  common  communications  protocol. 
“A  service  is  an  implementation  of  a  well-defined  piece  of  business  functionality, 
with  a  published  interface  that  is  discoverable  and  can  be  used  by  service 
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consumers  when  building  different  applications  and  business  processes.” 
(Obrien  1 )  These  services  are  combined  and  reused  to  meet  the  requirements  of 
business  processes  and  software  users. 

The  Coast  Guard  does  not  have  resources  to  simultaneously  redevelop 
legacy  system  functionality  and  implement  the  new  elements  of  SOA.  The  rich 
capabilities  contained  within  legacy  Command  and  Control  (C2)  applications  can 
be  reused  in  an  SOA  with  a  “wrapper.”  This  approach  provides  a  viable 
economic  option,  because  it  avoids  re-writing  the  existing  software.  Once 
service  enabled,  these  legacy  components  can  remain  operationally  intact  within 
the  current  architecture  and  be  made  available  as  services  at  the  same  time. 
“SOAs  are  flexible  because  each  service  encapsulates  the  underlying  platforms 
and  technologies  that  support  it.  The  services  provided  at  the  enterprise  level 
are  therefore  agnostic  to  those  specific  platforms  and  technologies.”  (Lau  1 1 ) 

Unfortunately  SOA  does  not  provide  the  perfect  solution  to  all  the  Coast 
Guard’s  information  sharing  and  application  integration  needs.  SOA  means 
different  things  to  different  people  and  the  Coast  Guard  needs  to  have  a  clear 
understanding  of  the  differing  technologies,  standards,  and  implementation 
methods.  Because  SOA  holds  so  much  promise,  all  the  major  software 
manufacturers  and  vendors  are  promoting  their  support  with  some  directly 
involved  in  developing  open  standards.  As  a  result,  every  major  development 
platform  now  officially  supports  the  creation  of  “service-oriented  solutions.”  (“The 
SOA  Vision”)  This  competition  between  vendors  with  different  standards  must  be 
approached  with  caution  as  it  may  actually  make  it  more  difficult  to  successfully 
develop  a  meaningful  SOA  to  meet  the  Coast  Guard’s  needs.  The  next  chapter 
will  examine  the  standards  and  technologies  used  to  implement  SOAs  with 
specific  recommendations. 

C.  THESIS  QUESTIONS 

This  thesis  aims  to  provide  sound,  supported,  informative,  and  valuable 
answers  to  Coast  Guard  IT  decision-makers  for  the  following  two  questions. 
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1.  How  Can  the  Coast  Guard  Implement  a  Service-Oriented 
Architecture  for  Command  and  Control? 

Traditional  descriptions  of  software  architectures  make  it  difficult  to  identify 
and  understand  the  trade-offs  between  quality  attributes  that  are  inherent  in  the 
design.  We  will  use  multiple  scenarios  and  use  cases,  in  addition  to  diagrams 
and  functionality  requirements,  to  make  these  critical  issues  easier  to 
understand.  Defining  the  architecture  in  terms  of  the  functionality  and  quality 
attribute  levels  of  each  component  should  allow  an  auditor  to  determine  the 
architecture’s  validity.  Our  answer  to  this  question  does  not  create  a  complete 
architecture,  however  it  does  establish  an  effective  starting  point  for  the  Coast 
Guard. 

2.  What  is  the  Optimal  Implementation  Plan  for  this  Coast  Guard 
Command  and  Control  (CGC2)  SOA? 

Almost  all  large  scale  software  and  IT  system  projects  fail,  so  a  “big  bang” 
approach  to  create  this  SOA  should  be  avoided.  Because  the  entire  SOA  will  not 
be  created  at  the  same  time,  the  Coast  Guard  needs  a  process  that  will  deliver 
value  in  the  form  of  usable  capabilities  in  an  incremental  and  iterative  manner. 
This  sequence  of  capabilities  should  determine  how  the  components  and 
architecture  evolve.  Our  proposed  iterative  method  will  include  an  evaluation  of 
the  system  requirements,  architecture,  and  implementation  plan  during  each 
repetition  of  the  cycle  that  guarantees  continuous  improvement.  This  plan  will 
also  incorporate  industry  best  practices  to  anticipate  and  address  predictable 
problems. 

D.  THESIS  ORGANIZATION 

Chapter  I  has  defined  the  problem  and  introduced  the  basic  approach  for 
our  solution.  The  remaining  chapters  of  this  thesis  are  organized  as  follows: 

•  Chapter  II  provides  a  synopsis  of  SOA  components  and  standards. 

•  Chapter  III  describes  an  SOA  for  Coast  Guard  Command  and 
Control. 

•  Chapter  IV  proposes  an  Implementation  Plan  for  that  architecture. 
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Chapter  V  contains  our  conclusions  and  recommendations  for 
future  research. 
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II.  SOA  BACKGROUND  INFORMATION 


A.  SERVICES  ORIENTED  ARCHITECTURE 

This  chapter  provides  background  information  about  SOA,  Web  services 
standards,  and  data  models  for  readers  new  to  the  subject  so  they  can  grasp  the 
material  presented  in  the  remaining  chapters. 

Service-Oriented  Architecture  is  a  software  design  methodology  that  uses 
loosely-coupled  services  to  perform  business  functions  or  processes.  These 
services  communicate  using  well-defined  standards  across  a  network.  Section  C 
describes  services  and  service-oriented  design  principles  in  detail.  Services 
send  XML-formatted  messages  that  relay  information  structured  in  accordance 
with  an  accepted  data  model.  Section  B  defines  the  basic  XML  terms  and 
Section  E  discusses  data  models. 

SOA  proponents  believe  it  can  help  businesses  (and  government 
agencies)  respond  more  quickly  and  cost  effectively  to  changing  environmental 
conditions.  “All  major  software  manufacturers  and  vendors  promote  support  for 
SOA  -  some  even  through  direct  involvement  in  the  development  of  open 
standards.  As  a  result,  every  major  development  platform  now  officially  supports 
the  creation  of  service-oriented  solutions.”  (“The  SOA  Vision”)  While  that 
statement  sounds  like  a  boon  for  businesses  and  government  organizations 
considering  an  SOA,  competing  standards  and  vendors  can  actually  make  it 
more  difficult  to  separate  the  marketing  hype  from  the  truly  valuable  technology 
to  determine  a  path  to  success.  We  outline  the  core  SOA  standards  in  Section 
D.  This  chapter  concludes  with  an  example  Web  service  in  Section  E. 

B.  XML 

The  Extensible  Markup  Language  (XML)  is  an  open  standard  for 
exchanging  structured  documents  and  data  over  the  Internet.  Authors  and 
“...designers  create  their  own  customized  tags,  enabling  the  definition, 
transmission,  validation,  and  interpretation  of  data  between  applications  and 
between  organizations.”  (“XML”)  A  schema  provides  a  framework  for  naming 
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and  storing  different  elements  of  information.  XML  Schema  Documents  (XSD) 
use  XML  to  describe  the  schema  for  a  certain  kind  of  XML  document  or 
message.  An  XML  message  recipient  can  use  the  appropriate  XSD  to  verify  the 
message’s  data  structure  and  format  using  a  process  called  validation.  Using 
XML  to  carry  both  the  meta  data  and  the  data  in  the  same  message,  composed 
using  an  agreed  upon  schema,  begins  to  solve  the  data  interoperability  problem. 

Because  XML  documents  contain  standard  structure  with  the  content,  they 
can  be  easily  converted  to  comply  with  another  XML  schema.  XML 
Transformation  documents,  written  in  the  Extensible  Stylesheet  Language 
Transformation  (XSLT)  language,  perform  this  function.  For  example,  we  may 
have  one  XSLT  that  reformats  an  XML  message  as  a  Web  page,  another  that 
outputs  a  plain-text  document  for  printing,  and  a  third  that  outputs  data  formatted 
as  expected  by  a  legacy  application.  To  summarize,  we  use  XML  to  “tag” 
content  in  a  message,  XSD  to  define  the  structure  of  the  tags,  and  XSLT  to 
reorganize  the  data  based  on  the  needs  of  a  specific  consumer. 

C.  SERVICES 

“A  service  is  an  implementation  of  a  well-defined  piece  of  business 
functionality,  with  a  published  interface  that  is  discoverable  and  can  be  used  by 
service  consumers  when  building  different  applications  and  business  processes.” 
(O’Brien,  Bass,  and  Merson  1)  Web  services  differ  from  generic  services 
because  they  use  SOAP-formatted  XML  envelopes  and  have  their  interfaces 
described  by  a  Web  Service  Description  Language  (WSDL)  document.  Section 
D  defines  both  SOAP  and  WSDL.  We  use  the  terms  service  and  Web  service 
interchangeably  throughout  this  thesis.  The  decision  to  use  one  or  the  other  will 
be  made  by  the  architecture  team  for  each  service,  when  it  designs  the  SOA. 

1.  Common  Principles  of  Service  Orientation 

The  authors  of  a  recent  Software  Engineering  Institute  report  on  SOA 
provide  the  following  service  oriented  design  principles.  They  establish  a  unique 
design  approach  for  building  Web  services  for  SOA.  “When  applied,  these 
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principles  succeed  in  standardizing  Web  services  while  preserving  their  loosely 
coupled  relationships.”  (Erl  53) 

Services  are  reusable.  Regardless  of  whether  immediate  reuse 
opportunities  exist,  services  are  designed  to  support  potential 
reuse. 

Services  share  a  formal  contract.  In  order  for  them  to  interact,  they 
need  not  share  anything  but  a  formal  contract  that  defines  the 
terms  of  information  exchange  and  any  supplemental  service 
description  information. 

Services  are  loosely  coupled.  They  must  be  designed  to  interact 
on  a  loosely  coupled  basis,  and  they  must  maintain  this  state  of 
loose  coupling.  This  is  closely  related  to  service  abstraction  and 
service  autonomy.  [Loosely  coupled  frameworks  allow  individual 
nodes  in  a  distributed  system  to  change  without  affecting  or 
requiring  change  in  any  other  part  of  the  system .] 

Services  abstract  underlying  logic.  The  only  part  of  a  service  that  is 
visible  to  the  outside  world  is  what  is  exposed  via  the  service’s 
description  and  formal  contract.  The  underlying  logic  (beyond  what 
is  expressed  in  the  description  and  formal  contract)  is  invisible  and 
irrelevant  to  service  requestors. 

Services  are  composable.  They  may  compose  other  services. 

This  possibility  allows  logic  to  be  represented  at  different  levels  of 
granularity  and  promotes  reusability  and  the  creation  of  abstraction 
layers. 

Services  are  autonomous.  The  logic  governed  by  a  service  resides 
within  an  explicit  boundary.  The  service  has  complete  autonomy 
within  this  boundary  and  is  not  dependent  on  other  services  for  the 
execution  of  this  governance. 

Services  are  stateless.  They  should  not  be  required  to  manage 
state  information,  since  that  can  impede  their  ability  to  remain 
loosely  coupled.  Services  should  be  designed  to  maximize 
statelessness  even  if  that  means  deferring  state  management 
elsewhere. 

Services  are  discoverable.  They  should  allow  their  descriptions  to 
be  discovered  and  understood  by  humans  and  service  users  who 
may  be  able  to  make  use  of  the  services’  logic.  Service  discovery 
can  be  facilitated  by  the  use  of  a  directory  provider,  or,  if  the 
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address  of  the  service  is  known  during  implementation,  the  address 
can  be  hard-coded  into  the  user’s  software  during  implementation. 

Services  have  a  network-addressable  interface.  Service  requestors 
must  be  able  to  invoke  a  service  across  the  network.  When  a 
service  user  and  service  provider  are  on  the  same  machine,  it  may 
be  possible  to  access  the  service  through  a  local  interface  and  not 
through  the  network.  However,  the  service  must  also  support 
remote  requests. 

Services  are  location  transparent.  Service  requestors  do  not  have 
to  access  a  service  using  its  absolute  network  address. 
Requestors  dynamically  discover  the  location  of  a  service  looking 
up  a  registry.  This  feature  allows  services  to  move  from  one 
location  to  another  without  affecting  the  requestors.  (O’Brien,  Bass, 
and  Merson  3-4) 

2.  Wrappers 

Architects  often  want  to  reuse  existing  applications  and  databases  in  their 
SOAs.  Unfortunately  almost  all  legacy  systems  cannot  operate  in  the  service 
environment  in  their  current  configuration.  Developers  solve  this  problem  by 
creating  a  wrapper,  special  software  that  resides  between  the  legacy  application 
and  the  SOA.  The  wrapper  exposes  the  legacy  application’s  functionality  or  data 
to  the  SOA  as  a  service.  The  wrapper  provides  all  the  security,  quality  of  service, 
and  service  orientation  principles  that  any  other  service  in  the  SOA  has.  The 
following  quote  illustrates  the  benefits  wrappers  can  provide: 

For  example,  at  telecom  company  Verizon,  the  service  called  "get 
CSR"  (get  customer  service  record)  is  a  complex  jumble  of  software 
actions  and  data  extractions  that  uses  Verizon's  integration 
infrastructure  to  access  more  than  25  systems  in  as  many  as  four 
data  centers  across  the  country.  Before  building  the  "get  CSR" 
service,  Verizon  developers  who  needed  that  critical  lump  of  data 
would  have  to  build  links  to  all  25  systems — adding  their  own  links 
on  top  of  the  complex  web  of  links  already  hanging  off  the  popular 
systems.  But  with  the  "get  CSR"  service  sitting  in  a  central 
repository  on  Verizon's  intranet,  those  developers  can  now  use  the 
simple  object  access  protocol  (SOAP)  to  build  a  single  link  to  the 
carefully  crafted  interface  that  wraps  around  the  service.  Those  25 
systems  immediately  line  up  and  march,  sending  customer 
information  to  the  new  application  and  saving  developers  months, 
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even  years,  of  development  time  each  time  they  use  the  service. 

(“ABCs  of  SOA”) 

Wrappers  provide  an  excellent  way  to  reuse  applications  already 
delivering  business  value.  However,  proper  IT  business  alignment  is  necessary 
to  ensure  proper  enforcement  of  control  and  management  policies.  Randomly 
wrapping  services  can  lead  to  security  and  performance  problems  inside  and 
outside  the  organization.  The  Web  service  wrappers  provide  a  “great  tactical 
approach”  for  SOA  development,  but  they  are  not  a  panacea.  (“Web  Services 
Wrapper”)  We  can  not  simply  wrap  all  our  legacy  systems  and  declare  SOA 
victory.  Ultimately,  SOA  aims  to  unlock  the  application  logic  and  data  from  the 
legacy  systems,  so  they  exist  as  native  services  within  the  SOA.  This  process 
frees  them  to  operate  at  their  logical  place  in  the  business  processes  and 
workflows,  without  the  artificial  constraints  of  the  legacy  systems. 

D.  WEB  SERVICE  STACK 

The  Web  services  stack  shows  the  collection  of  computer  networking 
protocols  that  define,  locate,  implement,  and  make  Web  services  interact  with 
each  other.  The  World  Wide  Web  Consortium’s  Web  Services  Architecture 
Working  Group  defined  technical  standards  to  ensure  interoperability  for  SOAs. 
The  Working  Group  divided  these  standards  into  the  following  six  areas: 
processes,  descriptions,  messages,  communications,  security  and  management: 
Figure  3  shows  a  modified  version  of  their  Web  Services  Architecture  Stack 
diagram. 
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Figure  3.  Web  Services  Architecture  Stack  (After  “Web  Services  Architecture” 

Figure  3-1) 


1.  Process  Layer 

The  Process  layer  describes  how  providers  publish  services  and 
requestors/consumers  discover  them.  The  Process  layer  utilizes  the  following 
standards: 

•  Universal  Description  Discovery  and  Integration  (UDDI):  UDDI  is  a 
directory  that  allows  businesses  to  register  their  services  so  that  the 
consumers  can  find  them. 

•  WS-Coordination:  This  specification  “describes  an  extensible 
framework  for  providing  protocols  that  coordinate  the  actions  of 
distributed  applications.  Such  coordination  protocols  are  used  to 
support  a  number  of  applications,  including  those  that  need  to 
reach  consistent  agreement  on  the  outcome  of  distributed 
activities.”  (“WS-Coordination”) 

2.  Description  Layer 

The  Description  layer  describes  how  the  service  provider  communicates 
the  specifications  for  invoking  the  Web  service  to  the  service  requestor.  The 
Description  layer  utilizes  the  following  standards: 
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•  Web  Service  Description  Language  (WSDL):  An  XML  document 
that  describes  the  interfaces  and  methods  that  a  service  provides. 

3.  Messages  Layer 

The  Messages  layer  describes  how  the  services  pass  information  in  the 
form  of  a  message.  The  Messages  layer  utilizes  the  following  standards: 

•  Simple  Object  Access  Protocol  (SOAP):  SOAP  is  a  protocol  used  to 
exchange  messages  between  systems  in  XML  format.  SOAP  has 
become  the  de-facto  standard  protocol  for  Web  services. 

•  WS-ReliableMessaqinq:  This  specification  describes  a  protocol  that 
allows  messages  to  be  transferred  reliably  between  nodes  in  the 
presence  of  software  component,  system,  or  network  failures. 
(“WS-ReliableMessaging”) 

•  WS-Addressinq:  This  specification  “provides  transport-neutral 

mechanisms  to  address  Web  services  and  messages.  Specifically, 
this  specification  defines  XML  elements  to  identify  Web  service 
endpoints  and  to  secure  end-to-end  endpoint  identification  in 
messages.  This  specification  enables  messaging  systems  to 
support  message  transmission  through  networks  that  include 
processing  nodes  such  as  endpoint  managers,  firewalls,  and 
gateways  in  a  transport-neutral  manner.”  (“WS-Addressing”) 

•  WS-Notification:  “The  Event-driven,  or  Notification-based, 

interaction  pattern  is  a  commonly  used  pattern  for  inter-object 
communications.  Examples  exist  in  many  domains,  for  example  in 
publish/subscribe  systems  provided  by  Message  Oriented 
Middleware  vendors,  or  in  system  and  device  management 
domains.”  (“WS-Notification”) 

•  WS-Eventinq:  “This  specification  describes  a  protocol  that  allows 
Web  services  to  subscribe  to  or  accept  subscriptions  for  event 
notification  messages.”  (“WS-Eventing”) 

4.  Communications  Layer 

The  Communications  layer  describes  how  messages  are  physically 
transported  across  the  network.  The  Communications  layer  utilizes  the  following 
Internet  protocols: 

•  Hypertext  Transfer  Protocol  (HTTP):  HTTP  is  the  standard 

mechanism  for  retrieving  Web  pages  and  associated  content.  It  can 
also  be  used  for  transmitting  data  from  the  client  to  the  server. 

•  Simple  Mail  Transfer  Protocol  (SMTP):  SMTP  is  the  standard 
mechanism  for  sending  email  from  the  client  to  the  server. 
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•  File  Transfer  Protocol  (FTP):  FTP  is  primarily  used  for  transferring 
files  from  one  computer  to  another  over  a  TCP/IP  network. 

5.  Security 

Security  occurs  at  all  layers  in  the  stack  and  it  provides  authenticity, 
integrity,  confidentiality,  and  non-repudiation.  Security  utilizes  the  following 
standards: 

•  WS-Security:  “This  specification  describes  enhancements  to  SOAP 
messaging  to  provide  message  integrity  and  confidentiality.  The 
specified  mechanisms  can  be  used  to  accommodate  a  wide  variety 
of  security  models  and  encryption  technologies.”  (“WS-Security”) 

•  WS-SecurityPolicy:  WS-SecurityPolicy  is  designed  to  work  with  the 
general  Web  Services  framework  including  WSDL  service 
descriptions,  UDDI  businessServices  and  bindingTemplates  and 
SOAP  message  structure  and  message  processing  model,  and 
WS-SecurityPolicy  should  be  applicable  to  any  version  of  SOAP. 
(“WS-SecurityPolicy”) 

•  WS-SecureConversation:  "This  specification  defines  extensions 
that  build  on  WS-Security  to  provide  a  framework  for  requesting 
and  issuing  security  tokens,  and  to  broker  trust  relationships.” 
(“WS-SecureConversation”) 

•  WS-Trust:  The  goal  of  WS-Trust  is  to  enable  applications  to 
construct  trusted  SOAP  message  exchanges.  This  trust  is 
represented  through  the  exchange  and  brokering  of  security 
tokens.  This  specification  provides  a  protocol  agnostic  way  to  issue, 
renew,  and  validate  these  security  tokens.  (“WS-Trust”) 

•  WS-Federation:  A  specification,  by  IBM  and  Microsoft,  for 

standardizing  the  way  companies  share  user  and  machine 
identities  among  disparate  authentication  and  authorization 
systems  spread  across  corporate  boundaries.  (“WS-Federation”) 

•  SAML:  “An  XML-based  framework  for  communicating  user 

authentication,  entitlement,  and  attribute  information.  As  its  name 
suggests,  SAML  allows  business  entities  to  make  assertions 
regarding  the  identity,  attributes,  and  entitlements  of  a  subject  (an 
entity  that  is  often  a  human  user)  to  other  entities,  such  as  a  partner 
company  or  another  enterprise  application.”  (“SAML”) 

6.  Management 

Management,  like  Security,  occurs  across  all  layers  in  the  stack. 
Management  provides  methods  for  monitoring  and  managing  services  and 

business  processes.  Management  utilizes  the  following  standards: 
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•  WS-Manaqeability:  “specification  introduces  the  general  concepts 
of  a  manageability  model  in  terms  of  manageability  topics  and  the 
aspects  used  to  define  them.”  (“WS-Manageability”) 

•  Business  Process  Execution  Language  for  Web  Services 
(BPEL4WS):  “The  Business  Process  Execution  Language  for  Web 
Services  provides  a  comprehensive  syntax  for  describing  business 
workflow  logic.  It  allows  for  the  creation  of  abstract  processes  that 
can  describe  business  protocols,  as  well  as  executable  processes 
that  can  be  compiled  into  runtime  scripts”  (Erl  100)  The  Business 
Process  Modeling  Notation  (BPMN)  provides  a  standardized 
graphical  notation  for  drawing  business  processes  in  a  workflow. 
Software  tools  easily  translate  BMPN  models  into  BPEL4WS  files. 

E.  DATA  MODELS  AND  INFORMATION  EXCHANGE 

Semantics  define  a  language’s  structure  and  meaning.  For  the  services  in 
an  SOA  to  be  interoperable,  the  services  exchanging  messages  must  understand 
the  semantics  of  the  data.  Therefore,  we  need  an  efficient  way  to  establish  an 
agreed  upon  structure  and  meaning  for  the  data  elements  in  our  XML  formatted 
messages.  Conceptual  data  models  and  XML  schemas  accomplish  this. 

Conceptual  data  models  (CDM)  show  the  overall  organizational  data 
structure  without  considering  the  ability  to  implement  the  structure.  SOAs 
employ  CDMs  to  avoid  the  point-to-point  mapping  problem  encountered  when 
sharing  data  between  systems.  For  example,  if  we  have  N  systems  in  our  SOA 
and  we  want  them  all  to  share  data  with  each  other,  point-to-point  mapping 
requires  N(N-1)  translations  between  them  which  is  approximately  N2.  Utilizing  a 
CDM  requires  2N  translations;  one  for  each  system  to  the  CDM  and  one  for  the 
CDM  back  to  each  system,  and  this  number  is  usually  much  smaller  than  N2. 
Interestingly,  Appendix  D  to  the  Coast  Guard’s  Common  Operational  Picture 
Operational  Requirements  Document  (COPORD)  shows  a  matrix  proposing 
point-to-point  mapping  between  nine  existing  stovepipe  systems.  The  72 
transformations  required  in  the  diagram  could  be  reduced  to  18,  a  reduction  of 
75%,  through  appropriate  use  of  a  CDM.  The  Coast  Guard  has  not  yet 
implemented  a  command  and  control  CDM. 
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Creating  a  CDM  has  one  negative  aspect.  The  data  modeling  and  related 
XML  schema  generation  efforts  increase  the  start-up  cost.  XML  schemas 
describe  an  XML  document’s  structure  and  validate  messages  in  the  SOA.  “This 
industry  best  practice  requires  work  up  front,  but  results  in  a  scalable  and  flexible 
solution.  The  instantiation  of  a  canonical  XML  Schema  based  on  that  model 
provides  a  consistent  target  ...  to  which  each  endpoint  system  maps.”  (Hutchins) 
Conceptual  data  modeling  benefits  outweigh  their  costs,  in  a  way  similar  to  the 
payback-to-cost  provided  by  the  Incremental  Evolutionary  approach  in  Chapter 
4’s  Figure  22. 

F.  EXAMPLE  WEB  SERVICE 

1.  Search  Pattern  Service  (SPS)  Description 

We  created  the  SPS  to  provide  an  example.  It  accepts  search  pattern 
parameters  and  returns  the  latitude  and  longitude  points  for  the  waypoints  along 
the  search.  Coast  Guard  readers  may  initially  dismiss  the  need  for  a  service  to 
generate  search  patterns.  We  already  have  many  different  systems  capable  of 
doing  this,  and  several  provide  much  more  robust  functionality.  However,  in 
addition  to  illustrating  what  a  service  can  do,  this  particular  example  highlights  a 
more  important  point.  The  Coast  Guard  has  recreated  the  same  functionality  in  a 
dozen  different  systems,  but  we  can’t  take  a  search  pattern  generated  by  the 
Sector  Command  Duty  Officer  (CDO)  and  automatically  import  it  into  the 
navigation  system  on  a  patrol  boat. 

Implementing  functionality  as  a  service  means  that  you  only  need  to  build 
it  once.  Thereafter,  anyone  can  use  it  anywhere  in  the  SOA.  Service 
modifications  only  happen  in  one  location,  not  in  each  separate  system.  The 
SPS  can  also  have  multiple  interfaces  so  that  many  different  applications  and 
devices  can  use  it.  This  service  calculates  the  same  search  pattern  coordinates 
for  every  user.  The  Sector  CDO  sees  the  exact  same  pattern  at  his  computer 
workstation  that  the  coxswain  on  the  small  boat  sees  on  his  SINS  equipment. 
The  C-130  sees  the  same  pattern  on  his  Cockpit  Display  Navigational  Unit 
(CDNU)  as  the  District  Commander  using  a  smart  phone.  However,  perhaps  we 
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don’t  want  it  to  calculate  the  same  pattern  for  every  user.  The  interface  can  also 
make  the  service  context-sensitive.  For  example,  the  small  boat  interface  would 
generate  search  patterns  that  avoided  rocky  shoals  but  the  helicopter  interface 
would  not. 

2.  Current  Features 

The  SPS  accepts  the  parameters  shown  in  Table  1  then  calculates  and 
returns  a  series  of  latitude/longitude  pairs.  Appendix  C  contains  the  SPS  source 
code.  It  currently  performs  three  search  patterns: 

•  Parallel  Search 

•  Sector  Search 


•  Expanding  Square  Search 


Search  Pattern 

Parallel 

Sector 

Expanding  Square 

Latitude 

X 

X 

X 

Longitude 

X 

X 

X 

X 

Width 

X 

Track  Spacing 

X 

X 

X 

Radius 

X 

Theta 

X 

Initial  Track 

X 

X 

Cycles 

X 

Table  1.  Search  Pattern  Service  Parameters 


3.  Potential  Future  Features 

The  initial  description  mentioned  one  potential  feature,  adjusting  the 
pattern  based  on  the  asset  type.  It  could  also  access  current  weather  and  sea 
conditions,  or  receive  updated  information  about  the  target,  and  then  dynamically 
adjust  the  search  pattern  parameters  accordingly.  Couple  this  capability  with  the 
integrated  navigation  systems  in  some  of  the  Coast  Guard’s  assets  and  it 
becomes  possible  to  improve  mission  effectiveness.  Currently,  changes  to 
search  patterns  require  the  coxswain  or  pilot  to  manually  stop  the  current  search 
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and  enter  a  new  one  with  the  updated  information.  Dynamic  updates  allow  the 
people  performing  the  mission  to  keep  their  eyes  and  attention  focused  on 
finding  the  survivor  rather  than  buried  in  a  navigation  computer  entering  new 
coordinates. 

4.  Java-based  Client  Application 

We  created  a  multi-platform  Java-based  client  to  demonstrate  this 
service’s  functionality  and  output.  Appendix  D  contains  the  Java  client  source 
code.  The  user  enters  parameters  into  the  form  boxes  and  initiates  the  service 
by  pressing  the  “Generate”  button.  This  client  initiates  a  request  to  the  service 
and  displays  the  result  in  the  “Results”  text  box.  Figure  4  shows  the  Java  client 
in  the  sector  search  mode.  Note  that  the  latitude  and  longitude  coordinates  are 
in  degrees  with  decimals.  If  we  needed  positions  in  degrees,  minutes,  seconds 
that  conversion  could  be  built  into  either  the  client  application  or  the  service  itself. 
This  client  would  probably  not  exist  within  the  Coast  Guard  SOA.  Most  services 
do  not  need  a  dedicated  user  client.  Integrated  user  interfaces,  called  composite 
applications,  fuse  the  functionality  and  output  of  many  services. 
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eoe 


Search  Type 
O  Parallel 

Search  Parameters 
Latitude 


0  Sector 


w  Expanding  Square 


22.03678 


Radius 


Initial  Track  90 


Longitude  -123.55678 
Theta 


30 


Results 

22.037458070405943 

22.037458070405943 

22.12079140373928 

22.110001532362393 

22.0378266031851 

22.0378266031851 

21.965651696208546 

21.995111421521564 

22.03675971277393 

22.03675971277393 

22.07840796556339 

22.038160644832338 

22.038136113194764 

22.038136113194764 


-123.55588299353424 

-123.55588299353424 

-123.55588299353424 

-123.51243820155518 

-123.55741210640711 

-123.55741210640711 

-123.60236304268574 

-123.63413198705916 

-123.55629813288391 

-123.55629813288391 

-123.47844139826552 

-123.46680389842568 

-123.55670601082142 

-123.55670601082142 


m 


(  Clear  )  Generate 


Figure  4.  Java  Client  -  Sector  Search 


G.  CONCLUSION 

This  chapter  defined  important  terms,  introduced  relevant  concepts, 
identified  applicable  industry  standards,  and  summarized  SOA  principles. 
Designing  and  building  an  SOA  requires  appropriate  data  standardization  and 
modeling  into  XML  schemas,  adhering  to  the  important  industry  standards  to 
appropriately  implement  the  technology  needed  to  support  the  layers  of  the  Web 
services  stack.  The  next  chapter  defines  an  SOA  for  Coast  Guard  command  and 
control  to  answer  our  first  thesis  question. 
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III.  DRAFT  USCG  COMMAND  AND  CONTROL  SERVICE 
ORIENTED  ARCHITECTURE  (CGC2  SOA) 


A.  INTRODUCTION 

This  chapter  provides  the  answer  to  our  first  thesis  question,  “How  can  the 
Coast  Guard  implement  a  Service-Oriented  Architecture  for  Command  and 
Control?”  We  begin  with  three  diagrams  in  Section  B;  one  to  introduce  the 
functional  areas,  one  to  describe  the  network  nodes,  and  one  to  illustrate  the 
systems  interfaces.  We  then  continue  with  a  scenario  in  Section  C  that 
demonstrates  the  CGC2  SOA  in  action.  Section  D  further  describes  the 
functional  areas  and  identifies  services  to  perform  them.  Section  E  discusses  the 
quality  attributes  that  significantly  influence  the  architecture.  Section  F  outlines 
the  conceptual  data  model  required  to  exchange  data  within  the  SOA.  Finally, 
Section  G  proposes  a  product  line  architecture  for  producing  composite 
applications.  The  answer  to  our  first  thesis  question  does  not  create  a  complete 
architecture.  However  it  does  establish  an  effective  starting  point  for  the  Coast 
Guard. 

B.  ARCHITECTURAL  VIEWS 

“Software  architecture  represents  a  common  abstraction  of  a  system  that 
stakeholders  can  use  as  a  basis  for  creating  mutual  understanding,  forming 
consensus,  and  communicating  with  each  other.”  (Clements,  Kazman,  Klien,  2) 
Diagrams  can  elegantly  summarize  complex  material,  clearly  showing  details  that 
otherwise  get  lost  in  lengthy  text  descriptions.  Architectural  views  are  diagrams 
that  provide  a  mechanism  for  separating  issues  and  concerns  when  analyzing  or 
building  an  architecture.  “They  let  us  consider  an  architecture  from  different 
perspectives.”  (Clements,  Kazman,  Klien,  8)  The  Department  of  Defense  (DoD) 
uses  a  framework  that  “defines  a  common  approach  for  DoD  architecture 
description,  development,  presentation,  and  integration”  called  the  DoD 
Architecture  Framework.  ( DoDAF  Deskbook  1-1)  We  created  our  diagrams  as 
DoDAF  “views”  in  order  to  facilitate  comparison  between  our  CGC2  SOA  and 
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existing  DoD  and  Coast  Guard  command  and  control  systems.  The  following 
diagrams  describe  our  proposed  CGC2  SOA. 

1.  High  Level  Operational  Concept  (OV-1) 

The  OV-1  displays  the  primary  CGC2  SOA  actors.  Participants  include 
Coast  Guard  units,  as  well  as  federal,  state  and  local  governments  and  non¬ 
governmental  agencies  (e.g.,  harbor  pilot  associations  and  shipping  companies). 
The  five  small  ovals  in  Figure  5  represent  the  CGC2  SOA  functional  areas.  The 
large  blue  oval  represents  the  combined  command  and  control  effect  those 
functions  produce,  making  the  whole  greater  than  the  sum  of  the  parts. 


Figure  5.  CGC2  SOA  Functional  Areas  and  Actors  (OV-1 ) 


2.  Operational  Node  Connectivity  Description  (OV-2) 

The  OV-2  shows  all  nodes  that  use,  produce  and  consume  information 
from  services  throughout  the  organization.  These  services  send  and  receive 
messages  formatted  in  the  Extensible  Markup  Language  (XML).  The  existing 
Coast  Guard  Data  Network  (CGDN)  provides  connectivity  between  network 
nodes,  but  does  not  reach  mobile  assets  (e.g.,  aircraft  and  small  boats). 
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Appendix  B  lists  our  proposed  CGDN  and  communications  systems 
requirements. 


Mobile  Devices 


Workstation 

Figure  6.  CGC2  SOA  Operational  Node  Connectivity  (OV-2) 

3.  Systems  Interface  Description  (SV-1) 

The  SV-1  identifies  the  interfaces  between  systems  and  system  nodes. 
The  diagram  in  Figure  7  shows  the  relationship  between  legacy  systems, 
elemental  and  composed  services,  and  the  composite  applications  that  utilize 
them.  The  gray  horizontal  boxes  abstract  many  complex  implementation  details. 
Although  each  legacy  system  has  unique  requirements,  SOA  allows  service 
providers  and  consumers  to  utilize  any  technology  that  supports  the  appropriate 
standards.  While  extremely  important,  these  non-architectural  issues  will  not  be 
addressed  in  this  thesis. 
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Figure  7. 


CGC2  SOA  Systems  Interface  Description  (SV-1) 


The  yellow  boxes  at  the  bottom  of  Figure  7  represent  legacy  applications 
that  must  be  “service-enabled.”  To  do  this,  software  called  wrappers  change  the 
existing  applications’  interfaces  without  affecting  current  functionality.  Wrappers 
expose  the  business  logic  and  data  from  legacy  applications  as  services,  which 
can  be  invoked  (used)  within  the  SOA.  The  wrappers  also  perform  data 
transformation  between  the  legacy  application  and  the  SOA’s  context  data 
model,  which  will  be  explained  in  Section  G.  Wrapping  multiple  legacy 
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applications  creates  a  pool  of  fine-grained  services.  The  green  shapes  in  Figure 
7  represent  all  the  fine-grained  services.  Each  one  typically  performs  a  single 
business  logic  or  data  access  function.  Five  different  fine-grained  service 
examples  are:  get  local  assets  (e.g.,  cutters,  boats,  aircraft)  currently  in  Alpha  or 
Bravo  status,  get  asset  positions,  get  OPAREA  weather,  filter  asset  list  based  on 
weather  limits,  and  sort  asset  list  based  on  distance  from  present  location  to 
target. 

As  they  pass  through  the  middle  gray  box,  the  fine-grained  services  are 
assembled  into  processes,  or  workflows,  that  perform  complex  business 
functions.  These  processes  or  assemblies  are  known  as  coarse-grained 
services.  The  orange  boxes  in  Figure  7  represent  the  five  functional  areas  that 
logically  group  the  course-grained  services.  The  fine-grained  services  described 
in  the  paragraph  above  could  be  linked  together  to  form  a  “nominate  asset” 
service  under  Planning.  This  service  would  take  a  geographic  position,  perform 
those  fine-grained  services,  and  return  a  list  containing  available  assets. 
Changing  the  fine-grained  services’  input  parameters  can  customize  this  coarse¬ 
grained  service.  For  example,  the  “nominate  surface”  service  would  include 
cutters,  boats,  and  Automated  Merchant  Vessel  Reporting  (AMVER)  vessels,  but 
the  “nominate  air”  service  would  only  return  aircraft.  Items  from  the  coarse¬ 
grained  services  inventory  can  be  reused  as  needed  anywhere  in  the  CGC2 
SOA.  In  this  way,  we  build  functionality  once,  and  then  quickly  deploy  it  across 
all  units  and  mission  areas. 

The  typical  user  interacts  with  the  services  through  a  composite 
application,  shown  as  blue  boxes  at  the  top  of  Figure  7.  A  Command  Duty 
Officer  (CDO)  needs  a  different  composite  application  than  the  Sector 
Commander,  which  will  differ  from  that  needed  by  the  district  staff  officer. 
Therefore  we  want  an  adaptive  and  inexpensive  way  to  create  a  composite 
application  tailored  for  each  user  type.  We  propose  a  product  line  architecture  to 
create  these  composite  applications  in  Section  G.  This  will  allow  the  Coast 


31 


Guard  to  quickly  create  multiple  composite  application  variations  needed  by 
different  command  and  control  user  groups. 

Now  that  we’ve  established  how  the  logic  and  data  from  existing  legacy 
applications  is  organized  (OV-1),  distributed  (OV-2),  and  consumed  (SV-1),  we 
will  bring  it  all  together  in  Section  C  with  a  scenario  showing  the  CGC2  SOA  in 
action. 

C.  SCENARIO 

The  following  scenario  illustrates  several  CGC2  SOA  services,  marked 
with  [service  name].  Throughout  these  events,  the  Sector  Command  Center 
watchstanders  use  electronic  checklists,  linked  to  tasking  and  communicating 
services  that  prompt  users  to  perform  required  actions  and  automate  information 
dissemination.  The  system  records  each  service  action  in  it’s  log  files.  In 
addition,  watchstanders  select  specific  actions  to  insert  into  their  standard  Coast 
Guard  logs,  now  kept  in  electronic  form. 

10  January  2008  -  [View  Plan ]:  Sector  San  Francisco’s  Response 
Department  staff  reviews  the  Guarterly  Operations  Schedule  for  events  during 
the  upcoming  week.  The  entire  weekly  schedule  must  be  reviewed  because 
several  maintenance  and  training  plans  have  changed  from  the  time  when  the 
quarter  schedule  was  created.  [Monitor  Request-Pull:  SANS]'.  The  staff  also 
accesses  the  local  vessel  arrival  notices  to  determine  Homeland  Security 
boarding  and  escort  activities.  [Create  Plan]'.  The  staff  creates  a  weekly 
schedule  that  balances  competing  demands  for  operational  assets.  [Create 
Task]:  They  create  detailed  tasks  that  include  patrol  areas  and  relevant  available 
information  about  the  target  vessels,  cargo  and  crew  members.  [Approve  Plan]'. 
The  Sector’s  command  staff  electronically  reviews  the  Weekly  Schedule  and 
approves  it.  [Assign  Plan,  Assign  Tasks,  Send  Message]'.  The  approval  triggers 
the  system  to  assign  the  plan  and  associated  tasks  to  all  units.  [View  Plan,  View 
Task]'.  Any  authorized  user  can  access  the  approved  schedule  and  associated 
tasks. 
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16  January  2008  -The  Rescue  21  system  detects  a  Mayday  call.  [Monitor 
Receive-Push:  Rescue21  DF]\  It  generates  an  alert  that  includes  an  estimated 
position  (triangulated  from  direction  finding  antennas)  and  the  Mayday  call’s 
digital  recording.  The  communications  watchstander  unsuccessfully  attempts  to 
hail  the  vessel  on  the  radio.  [Create  Case,  Modify  Case]:  The  CDO  creates  a 
SAR  case  and  appends  the  alert  to  the  case  file.  The  Sector  Command  Center 
watchstanders  listen  to  the  digital  recording.  The  position  from  the  Rescue  21 
alert  does  not  correspond  to  what  the  person  says  during  the  Mayday  call. 
Another  fishing  vessel  radios  to  report  they  overhead  the  distress  call.  This 
vessel  reports  that  the  Mayday  came  from  the  “LUCKY  LADY”,  and  that  they 
heard  the  victim  say  the  vessel  had  two  people  on  board.  [Modify  Case]:  The 
CDO  adds  this  information  to  the  case  file.  [Report  Request ]:  The  CDO  queries 
available  databases  for  information  about  vessels  with  the  name  “LUCKY  LADY.” 
[Monitor  Receive:  SARSAT]:  Shortly  thereafter  the  Sector  receives  a  SAR 
Satellite  (SARSAT)  alert  from  an  unregistered  Emergency  Position  Indicating 
Radiobeacon  (EPIRB)  reporting  a  position  0.5  nautical  miles  from  the  Rescue  21 
alert  position.  [Report  Generator]'.  The  CDO  receives  a  report  back  from  the 
database  query  listing  3  vessels  within  the  Sector  San  Francisco  area  of 
responsibility.  The  system  matches  the  registration  number  from  the  EPIRB  alert 
to  a  vessel  in  the  database  report.  [Modify  Case]:  The  CDO  inserts  the  SARSAT 
alert  and  matching  vessel  record  from  the  database  query  into  the  case  file.  The 
CDO  does  the  same  for  all  subsequent  information  related  to  the  case. 

The  SAR  case  creation  triggers  the  nomination  of  available  assets. 
[Available  Assets ]:  The  Sector  CDO  receives  a  list  with  aircraft,  boats,  and 
cutters.  Assets  marked  green  have  the  appropriate  readiness  level  and  ability  to 
operate  in  the  forecasted  environmental  conditions.  The  remaining  assets  are 
marked  in  yellow  or  red.  [Assign  Case]:  The  CDO  selects  an  HH-65  helicopter 
(6501)  from  AIRSTA  San  Francisco  and  a  4T  boat  (41001)  from  Station  Golden 
Gate.  [Create  Message,  Send  Message ]:  The  SAR  case  and  associated 
information  is  sent  to  both  responding  units.  [Create  Report,  Create  Message, 
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Send  Message]:  The  CDO  sends  the  Sector  commander  and  staff  a  summary 
report  with  a  hyper-link  allowing  recipients  to  view  the  SAR  case  file. 

[Search  Pattern]'.  The  system  generates  search  patterns  based  on  the 
reported  positions,  selected  assets,  vessel-in-distress  size  and  type,  number  of 
suspected  people  in  the  water,  and  the  forecasted  weather.  [CASP]:  These 
proposed  search  patterns  include  probability  of  detection  information  that  allows 
the  CDO  to  verify  their  appropriateness.  [Create  Task]'.  The  CDO  creates 
specific  tasks  for  the  6501  and  41001  to  execute  these  search  patterns.  [Assign 
Task,  Create  Message,  Send  Message ]:  The  CDO  sends  search  pattern  tasks  to 
the  responding  units  in  a  format  that  automatically  loads  into  their  navigation 
display  systems.  The  CDO  sends  a  summary  report  to  the  Sector  commander 
and  staff. 

[Database  Query:  A  OPS]:  6501  and  41001  dispatch  to  perform  their 
assigned  tasks  and  their  change  in  status  is  automatically  recorded.  [Monitor 
Receive-Push:  Blue  Force  Tracker]-.  Throughout  the  following  events,  the  CDO 
receives  helicopter  and  boat  position  and  status  information.  The  helicopter 
arrives  on  scene  with  the  vessel,  lowers  a  pump  to  the  vessel,  and  recovers  one 
person  from  the  water.  [Create  Message,  Send  Message]'.  6501  sends  patient 
data  to  Sector  San  Francisco.  [Create  Message,  Send  Message]-.  6501  departs 
to  take  the  victim  to  a  nearby  hospital  and  the  CDO  forwards  the  available  patient 
data  to  the  local  emergency  medical  services.  [Create  Message,  Send 
Message]'.  The  CDO  sends  updated  target  vessel  position  information  to  41001 
during  its  transit  from  the  station  to  the  scene.  [Modify  Case]:  41001  locates  the 
vessel  with  the  remaining  person  onboard  and  tows  it  back  to  port.  The  CDO 
marks  the  SAR  case  complete.  [Report  Request,  Report  Aggregator,  Report 
Generator]-.  This  action  triggers  several  reports,  including  one  that  automatically 
initiates  and  populates  the  reports  required  from  the  small  boat  and  aircraft  with 
the  case  file  information. 

17  Jan  2008  -  [e/VOAD]:  a  container  ship,  M/V  OCEAN  TRADER, 

scheduled  to  arrive  at  2300  submits  an  updated  Advanced  Notice  of 
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Arrival/Departure  reporting  they  have  been  delayed  18  hours.  [Monitor  Receive- 
Push:  eNOAD,  Task  Schedule  Check]:  Sector  San  Francisco  receives  the  report 
from  the  National  Vessel  Movement  Center.  [Create  Message,  Send  Message ]: 
This  ship  was  already  scheduled  for  boarding  and  escort  into  port  based  on 
irregularities  in  the  cargo  manifest.  Sector  San  Francisco  originally  assigned  this 
task  to  USCGC  TERN  and  a  boarding  team  from  the  Vessel  Boarding  and 
Search  Team  (VBST).  [Receive  Message ]:  The  CDO  receives  the  alert  message 
indicating  that  OCEAN  TRADER’S  delay  impacts  an  assigned  task.  The  alert 
shows  a  schedule  conflict  between  the  new  boarding  time  and  TERN’s  dockside 
maintenance  period.  It  lists  two  alternatives  for  the  escort  duty,  USCGC  PIKE 
and  41010  from  Station  San  Francisco.  [Assign  Task,  Create  Message,  Send 
Message ]:  The  CDO  selects  PIKE  and  the  service  automatically  reassigns  the 
tasks.  The  service  updates  the  VBST’s  task  to  reflect  the  new  cutter  assignment. 
[Monitor  Receive-Push:  A/S]:  Based  on  the  task  assignment,  PIKE  receives 
OCEAN  TRADER’S  position  information  from  the  Automated  Identification 
System. 

D.  FUNCTIONAL  AREAS 

The  actions  (operations)  and  capabilities  performed  by  the  system  for  the 
user  defines  the  systems’  functionality.  We  divide  our  SOA’s  functionality  into 
five  different  areas  as  indicated  in  Figure  5  above.  This  section  describes  these 
areas  in  detail,  identifies  the  legacy  stovepipe  systems,  and  defines  a  small 
portion  of  the  services  required  to  implement  the  architecture. 

1.  Planning 

The  planning  area  encompasses  all  mission  planning,  event  scheduling, 
and  resource  allocation  functions.  It  corresponds  to  the  “planning”  capability  in 
the  Command  Center  Program  Manual  (CCPM).  It  includes  deliberate  planning 
operations,  and  crisis  action  planning  for  emergent  events  such  as  search  and 
rescue,  marine  environmental  protection  response  and  disaster  response, 
a.  Discussion 

The  planning  area’s  base  services  and  data  model  must  be 

carefully  constructed.  They  must  contain  enough  details  to  meet  individual 
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planner’s  needs  at  all  levels,  without  including  so  many  details  as  to  become 
cumbersome  and  unmanageable.  Given  the  wide  range  of  missions  and  scope 
of  operations,  all  planners  do  not  have  the  same  needs.  Users  at  each  level 
need  the  functionality  and  appropriate  user  interface  for  their  mission  area. 
Some  information  applies  to  all  missions,  but  individual  communities  will  extend 
the  basic  structure  with  details  specific  to  their  requirements.  The  challenge  lies 
in  ensuring  each  planner  has  the  details  they  need  to  effectively  plan  their 
mission,  without  overwhelming  the  system. 

The  following  deliberate  planning  cycle  example  illustrates  the 
needs  of  Coast  Guard  planners.  At  the  strategic  level,  the  area  command  staff 
promulgates  annual  goals  and  targets.  Each  district  takes  those  goals  and 
creates  the  operational  plan  for  their  subordinate  sectors.  The  sector  staff  turns 
those  planning  goals  into  tactical  missions  assigned  to  individual  response  units. 
Each  unit  creates  a  unit  level  plan  to  assign  resources  and  personnel  for  each 
mission  based  on  their  personnel  and  equipment  readiness.  This  multi-level 
process  happens  in  each  mission  area,  for  each  iteration  of  the  deliberate 
planning  cycle. 

This  process  would  be  relatively  straightforward  if  we  only 
considered  law  enforcement,  vessel  safety  inspection,  or  any  one  individual 
mission.  It  becomes  much  more  complex  when  we  expand  the  planning  needs 
at  each  step  in  the  process  to  10  or  20  different  missions.  The  staff  at  a  sector 
continuously  plans  for  law  enforcement,  homeland  security,  vessel  safety,  and 
port  state  compliance  operations,  just  to  name  a  few.  While  these  operations 
share  some  common  planning  details,  each  mission  area  does  have  unique 
content.  Sector  command  centers  additionally  need  to  perform  crisis  action 
planning  to  respond  to  SAR,  marine  accidents,  and  pollution  incidents.  One  rigid 
system  will  not  meet  the  planning  needs  for  all  missions  at  all  organizational 
levels. 

The  Coast  Guard  needs  a  well  balanced,  component-based 

planning  system  that  can  provide  and  integrate  tailored  solutions  specialized  for 
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different  users  and  missions.  Consider  the  scenario  in  Section  C  above.  In  the 
CGC2  SOA  planning  services,  efficiency  and  accuracy  prevail  up  and  down  the 
chain-of-command,  in  stark  contrast  to  current  stovepipe  planning  procedures. 
As  the  typical  deliberate  planning  cycle  currently  happens,  planners  have  their 
own  system  to  document  and  pass  information  at  each  level.  Strategic  guidance 
lives  in  Microsoft  Word  documents  or  message  traffic.  Operational  planners 
create  a  local  document,  spreadsheet  or  small  database  to  manage  their  data. 
Often,  they  email  these  files  to  subordinate  units  or  place  them  in  a  public  folder 
on  a  shared  server.  Each  unit  then  creates  a  local  system  for  managing  their 
tactical  scheduling,  as  well  as  other  local  functions.  This  inherently  inefficient 
procedure  limits  our  ability  to  respond  in  the  dynamic  environment.  Status 
changes  made  at  the  unit  level  (as  when  the  USCGC  TERN  was  no  longer 
available  in  the  scenario)  do  not  necessarily  get  reported  back  up  the  chain.  A 
well  constructed  planning  system  will  give  decision  makers  at  all  levels  the  most 
accurate  and  timely  information  to  make  intelligent  decisions.  Improved  decision 
making  enables  us  to  better  serve  our  customers  and  more  effectively  use  our 
scarce  resources. 

b.  Legacy  Planning  Systems 

The  following  legacy  planning  systems  can  provide  functionality  in 
the  CGC2  SOA: 

•  Maritime  Homeland  Security  Operational  Planning  System 
(MHS-OPS):  a  homeland  security  operational  and  tactical 
mission  planning  and  scheduling  application. 

•  Computer  Aided  Search  Planning  (CASP):  a  SAR  planning 
tool  used  to  determine  search  object  drift,  over  a  defined 
time,  in  an  off  shore  oceanic  environment. 

•  Joint  Automated  Worksheet  (JAWS):  a  SAR  planning  tool 
used  to  determine  search  object  drift  over  time  and  calculate 
optimal  search  areas  utilizing  available  assets. 

•  Search  and  Rescue  Optimal  Planning  System  (SAR  OPS): 
a  SAR  planning  tool  that  uses  environmental  data  to  develop 
optimal  search  plans  based  on  a  defined  “effort”,  or  resource 
hours  available. 
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c.  Planning  Services 

The  following  descriptions  provide  a  service  framework  to  meet  the 
planning  needs  described  above.  The  first  six  define  general  tasking  services  we 
will  reuse  in  other  Coast  Guard  SOAs: 

•  Create  Plan:  Create  and  populate  a  new  plan.  This  includes 
options  for  several  different  plan  types  including  JOPES, 
ICS,  Annual  Schedule,  Quarterly  Schedule,  and  Weekly 
Schedule. 

•  Modify  Plan:  Changes  data  elements  in  existing  plans.  This 
service  also  appends  any  supporting  tasks  to  the  plan. 

•  View  Plan:  Displays  existing  plans  in  various  formats.  This 
service  may  be  called  by  the  reporting  services. 

•  Validate  Plan:  Error  and  omission  check. 

•  Approve  Plan:  Tracks  a  plan’s  review  and  approval  by  the 
chain  of  command. 

•  Assign  Plan:  Assign  a  plan  to  a  subordinate  unit. 

•  Available  Assets:  Generates  a  list  of  assets  in  Bravo  or 
Alpha  status,  located  within  the  response  range  of  a  given 
geographic  position  at  a  given  time. 

•  CASP  Service:  Generates  search  pattern  “probability  of 
detection”  graphic. 

A  case  contains  information  about  a  specific  Coast  Guard  mission 
event.  Any  mission  area  can  create  a  case,  however  law  enforcement,  SAR,  and 
Marine  Safety  events  typically  initiate  them.  Cases  also  store  intelligence 
information  related  to  a  specific  event  or  entity  (vessel,  person,  cargo,  facility, 
company).  We  discuss  cases  in  the  planning  section  because  planning  typically 
happens  in  conjunction  with  a  case  being  created.  Cases  also  fit  in  the  reporting 
section  although  we  do  not  discuss  them  there. 

•  Create  Case:  Create  and  populate  a  new  case.  This 
includes  options  for  several  different  case  types,  like  Search 
and  Rescue,  Law  Enforcement,  and  Marine  Investigation. 

•  Modify  Case:  Makes  changes  to  data  elements  in  existing 
cases.  This  service  also  appends  supporting  information 
and  electronic  documentation  (evidence)  to  the  case. 
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•  View  Case:  Displays  existing  cases  in  various  formats. 

Reporting  services  may  call  this  service. 

•  Assign  Case:  Assign  a  case  to  a  subordinate  unit. 

d.  Planning  Conclusion 

The  Coast  Guard  has  taken  a  step  in  the  right  direction  with  the 
prototype  MHS-OPS  system.  It  implements  some  of  the  planning  functionality 
described  above,  and  this  shows  promise.  However,  in  typical  Coast  Guard 
fashion,  we  limited  it  to  only  meet  the  needs  of  one  mission.  This  system  does 
offer  an  excellent  entry  point  for  building  our  CGC2  SOA’s  planning  functions.  To 
begin  with,  MHS-OPS  must  be  service-enabled  and  integrated  into  the  SOA. 

2.  Tasking 

Once  we  have  planned  our  operations,  the  services  in  the  tasking 
functional  area  must  enable  effective  resource  assignment.  For  this  discussion, 
we  define  tasking  as  the  point  in  the  process  where  a  decision-maker  directs  a 
specific  asset  to  go  to  an  assigned  point  to  perform  a  particular  objective.  Each 
plan  usually  includes  multiple  tasks. 

a.  Discussion 

Within  the  Coast  Guard  “we  push  both  authority  and  responsibility 
to  the  lowest  possible  level.  Our  ethos  is  that  the  person  on  scene  can  be 
depended  upon  to  assess  the  situation,  seize  the  initiative,  and  take  the  action 
necessary  for  success.”  ( America’s  Maritime  Guardian  52)  This  organizational 
culture  stems  from  “Coasties”  .operating  without  constant  communication  with 
their  superiors  over  the  last  two-hundred  seventeen  years.  We  still  embrace  this 
autonomous  operational  environment  today.  Operators  use  their  commander’s 
stated  goals  and  applicable  Coast  Guard  policies  as  the  basis  for  their  on-scene 
decisions.  Commanders  expect  situations  to  change  as  assets  operate  in  a 
dynamic  environment.  Therefore,  our  tasking  services  will  focus  on  telling  an 
asset  to  “go  and  do”  without  encumbering  them  with  overly  complex  task 
descriptions. 

The  services  within  this  functional  area  provide  the  following 

information:  asset  being  tasked,  user  assigning  task,  action  to  perform,  place, 
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time,  and  target  description.  Section  F  describes  this  data  structure.  The  place 
and  target  aspects  provide  a  dramatic  improvement  over  existing  capabilities. 
The  place  information  includes  track-lines,  search  patterns,  and  geographic 
points.  The  target  information  contains  sufficient  detail  for  the  asset  to  locate  and 
identify  the  object,  including  description  and  tracking  information  from  all 
connected  systems.  The  ability  to  electronically  transmit  and  then  automatically 
display  and  utilize  information  from  other  sensors  and  systems  will  significantly 
improve  Coast  Guard  command  and  control. 

b.  Legacy  Tasking  Systems 

The  following  legacy  tasking  system  can  provide  functionality  in  the 

CGC2  SOA: 

•  Incident  Command  System  (ICS):  a  standardized  national 
response  management  system  used  during  crisis  and  non¬ 
crisis  events. 

c.  Tasking  Services 

The  following  descriptions  provide  the  framework  for  creating 
services  to  meet  the  tasking  needs  described  above.  The  first  four  were  written 
as  general  tasking  services  that  we  will  reuse  in  other  Coast  Guard  SOAs. 

•  Create  Task:  Create  a  new  task. 

•  Modify  Task:  Modify  existing  tasks. 

•  View  Task:  View  existing  tasks.  The  reporting  module 
services  can  also  call  these  services.. 

•  Assign  Task:  Assign  a  task  to  a  subordinate  unit. 

•  Scheduled  Task  Check:  Compares  existing  task 

requirements  with  the  associated  asset’s  current  or 
scheduled  readiness  condition.  A  conflict  triggers  the 
Available  Asset  service  to  prompt  the  CDO  with  a 
replacement  candidate  list. 

•  Search  Pattern:  Generates  positions  for  a  search  pattern 
based  on  standard  inputs,  see  Chapter  2  for  more  details. 

•  Environmental  Limits  Check:  Accepts  weather  data  and 
asset  type  and  compares  the  asset’s  operational  limits  to  the 
forecasted  weather.  It  returns  a  “go/no  go”  recommendation 
for  each  asset,  including  the  exceeded  limits  that  cause  a 
“no  go” 
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•  Create  Target:  Compiles  position  and  other  related  track 
information  for  transmission  to  an  asset.  Provides  several 
output  formats  to  meet  different  asset  navigation  and  display 
systems’  needs. 

•  Intercept  Target:  Receives  information  from  “Create  Target” 
service  and  generates  local  intercept  solution  displayed  on 
the  assets  navigation  or  display  system.  An  enhanced 
version  fuses  the  external  target  data  with  the  asset’s 
organic  sensors  to  produce  a  more  accurate  intercept 
solution. 

d.  Tasking  Conclusion 

As  with  the  Planning  services,  the  base  Tasking  services  need  to 
address  the  principal  mission  area  details.  We  will  develop  additional  services  to 
provide  the  unique  functionality  required  in  each  mission  area. 

3.  Communicating 

The  communication  functional  area  provides  the  SOA’s  backbone 
essential  to  the  system’s  success.  The  best  planning  and  tasking  in  the  world 
accomplishes  nothing  if  no  one  knows  about  it.  The  communications  services  will 
generate  and  disseminate  many  routine  information  alerts  as  well  as  enable  real¬ 
time  and  asynchronous  communication  between  personnel  and  systems.  At  the 
system  level,  it  will  conduct  messaging  between  services.  Services  generate 
messages  automatically  and  invisibly  to  most  users,  but  these  important 
messages  implement  the  planning  and  tasking  functions  already  discussed.  The 
following  paragraphs  highlight  some  differences  between  personal  messaging 
and  service  messaging. 

a.  Discussion 

Service  messaging  in  the  SOA  requires  no  user  action,  which 
enables  great  efficiency  and  performance.  Removing  the  human  element  from 
routine  monitoring,  data  fusion  and  transmission  increases  communications 
quality  and  timeliness.  Consider  the  HLS  escort  and  boarding  scenario  without 
SOA.  The  MA/  Ocean  Trader  updates  its  arrival  time  at  0500  but  the  CDO  is 
busy  preparing  the  morning  brief.  The  assistant  duty  officer  (ADO)  checks  SANS 
during  the  morning  watch  relief,  but  he  only  pauses  long  enough  to  glance  at  the 
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list  and  log  the  time  change.  In  the  midst  of  watch  reliefs,  morning  arrivals,  and 
briefings,  the  ADO  forgets  to  pass  the  change  to  the  oncoming  watch.  Mid¬ 
morning,  the  new  CDO  reviews  the  previous  logs  and  sees  the  arrival  change. 
He  asks  the  new  ADO  what  action  has  been  taken.  The  ADO  checks  SANS  and 
verifies  the  new  arrival  time.  The  ADO  calls  the  unit,  and  leaves  a  message  with 
the  seaman  who  answers  the  phone.  He  follows  it  up  with  an  email  to  the 
executive  officer  (XO),  who  is  away  from  the  unit  until  mid-afternoon.  The  ADO 
expects  the  cutter  to  notify  the  VBST  about  the  time  change.  Upon  returning  to 
the  unit,  the  XO  grants  liberty  to  her  hard  working  crew  and  meets  with  the 
commanding  officer  (CO).  The  work  day  has  ended  by  the  time  she  checks  her 
email  and  sees  the  time  change.  She  immediately  talks  to  the  CO,  sends  a  page 
to  her  crew,  and  then  calls  the  CDO  to  remind  them  about  the  cutter’s  dockside 
in  the  morning.  The  CDO  looks  up  the  sector’s  vessel  status  list  and  sees  the 
PIKE  is  available.  He  passes  that  information  to  the  oncoming  watch  later  that 
evening.  After  the  watch  turns  over,  the  oncoming  watch  sends  a  tasking  email 
to  the  cutter  and  the  VBST.  However,  it’s  2130,  and  the  VBST  is  standing  on  the 
dark  pier  ready  to  conduct  the  boarding. 

When  you  replace  the  over-extended,  multitasked  human  element 
with  an  always-running  service,  communications  improve.  In  the  service-enabled 
HLS  escort  scenario,  a  monitoring  service  (described  in  the  next  section) 
continuously  checks  a  legacy  system  and  immediately  alerts  the  duty  officer 
when  the  target  vessel  changes  its  arrival.  A  tasking  service  automatically 
identifies  the  schedule  conflict  for  the  assigned  unit  and  proposes  alternative 
resources  to  select.  Once  the  CDO  has  made  a  choice,  a  communications 
service  automatically  generates  and  sends  messages  alerting  all  involved  units 
to  the  change  in  tasking,  giving  all  concerned  ample  time  to  adjust  their 
schedules.  A  service  replaces  communications  that  would  otherwise  require 
humans  to  perform  telephone  or  email  transmittals. 

With  a  better  understanding  about  service  messaging  in  the  SOA, 
we  can  address  communications  between  the  SOA  and  people  via  instant 
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messaging.  Instant  messaging  has  become  a  valuable  command  and  control 
communications  capability.  Messages  are  sent  via  computer  or  Short  Message 
Service  (SMS)  over  a  cellular  phone.  The  SOA  includes  services  that  generate 
instant  messages,  however,  we  must  take  care  when  creating  them.  A  service 
can  just  as  easily  message  one  recipient  as  100.  Over-messaging  users  may 
glut  and  desensitize  users,  so  they  may  miss  a  vital  message  among  the  fodder. 
Like  the  diverse  planning  and  tasking  needs  of  our  various  mission  areas,  we 
have  diverse  communications  needs  across  different  individuals  in  our  service. 
Some  individuals  focus  on  details  while  others  wish  to  grasp  only  big  picture 
changes.  Senior  officers  usually  have  less  interest  in  minor  changes  than  a 
program  manager  would  have.  The  messaging  services  need  to  address  these 
diverse  needs  as  well,  providing  a  common  base  structure  applicable  to  all  users, 
while  allowing  personalization  at  the  individual  level. 

b.  Legacy  Communications  Systems 

The  following  legacy  communications  systems  can  provide 
functionality  in  the  CGC2  SOA: 

•  Coast  Guard  Message  System  (CGMS):  a  system  that 
transmits  and  receives  text  messages. 

•  Rescue  21  (R21):  USCG’s  modernized  distress 

communications  system,  providing  911 -like  service  to 
mariners  over  VHF  and  UHF  radio. 

c.  Communicating  Services 

The  following  descriptions  provide  the  framework  for  creating 
services  to  meet  the  communicating  needs  described  above.  They  were  written 
as  general  communicating  services  we  can  reuse  in  other  Coast  Guard  SOAs. 
These  services  create  a  publish  and  subscribe  capability  that  will  push  and  pull 
messages  through  the  system  in  a  manner  transparent  to  the  user: 

•  Create  Message:  Creates  and  “publishes”  a  message  as  the 
requestor  specifies. 

•  Receive  Message:  Subscribes  to  a  publishing  service  and 
typically  serves  as  the  initiating  event  in  a  work  flow  or 
business  process. 
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•  Send  Message:  The  create  message  service  calls  this 
service  to  transmit  a  message.  When  a  unit  doesn’t  have 
coverage,  such  as  a  cutter  or  aircraft,,  this  service  will 
transmit  the  message  to  the  Forward  Message  service.. 

•  Forward  Message:  Provides  a  store-and-forward  message 
repository.  When  units  do  not  have  coverage,  this  service 
holds  the  message  and  sends  it  when  they  become 
available. 

d.  Communicating  Conclusion 

The  messages  that  flow  within  the  SOA  between  services  and 
people  dramatically  improve  the  communications  capabilities  of  the  Coast  Guard. 
Numerous  proprietary  and  open  instant  messaging  standards  exist  for  us  to 
choose  from.  Many  government  and  military  applications  have  embraced  the 
Extensible  Messaging  and  Presence  Protocol  (XMPP)  open  standard.  The 
Marine  Corps  recently  adopted  XMPP  as  their  instant  messaging  standard.  The 
Coast  Guard  must  research  the  available  options  and  choose  the  standard  that 
will  best  meet  our  needs.  However,  we  should  consider  XMPP  first. 

4.  Monitoring 

A  large  part  of  any  command  and  control  system’s  success  hinges  on  its 
ability  to  monitor  the  environment.  The  typical  C2  system  monitors  blue  (friendly) 
force  positions,  operational  status,  and  endurance,  usually  in  separate  displays. 
It  has  sensors  (e.g.,  radars,  cameras)  that  monitor  various  environmental  aspects 
to  enhance  situational  awareness,  but  these  proprietary  and  closed  systems 
usually  cannot  share  information  with  third  parties.  The  CGC2  SOA  monitoring 
services  provide  environmental  data  from  isolated  sensors  to  the  SOA,  allowing 
any  participant  with  the  appropriate  permissions  to  access  the  data. 

a.  Discussion 

Effective  command  and  control  requires  monitoring,  collecting  and 
fusing  a  tremendous  amount  of  information.  Our  situational  awareness  hinges 
on  our  ability  to  repeatedly  access  the  appropriate  information  sources,  evaluate 
the  data,  and  make  the  right  conclusions.  We  consult  many  data  sources  several 
times  during  each  watch,  in  each  operations  center,  in  each  sector,  in  each 

district,  in  each  area.  The  Coast  Guard  expends  hundreds  of  man-hours  each 
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day,  having  highly  skilled  people  sift  through  disjointed  information  displays 
expecting  them  to  correctly  interpret  the  data  and  make  the  right  judgments  at 
the  right  time.  However,  due  to  the  sheer  information  mass,  we  often  miss  that 
elusive  data  tidbit  that  would  make  it  all  clear.  As  currently  practiced,  fusion 
requires  much  human  effort,  achieves  modest  results,  and  costs  a  lot.  The 
services  in  the  monitoring  functional  area  can  automate  the  process  a  great  deal, 
providing  the  most  valuable  information  to  the  user. 

The  SARSAT  system  is  a  good  example  of  a  stovepipe  sensor 
system.  The  system  monitors  the  world’s  oceans  for  Emergency  Locator 
Transmitters  (ELT),  set  off  when  people  are  in  distress  on  the  sea.  The  U.S. 
Mission  Control  Center  (USMCC)  in  Suitland,  Maryland,  monitors  the  entire 
system.  When  they  receive  an  ELT,  they  report  it  to  the  Joint  Rescue 
Coordination  Center  (JRCC)  in  the  distress  region.  The  JRCC  then  passes 
tasking  on  the  Sector  who  tasks  the  unit.  This  entire  process  happens  by  voice 
telephone  communications,  slowing  the  information  flow.  Directly  feeding  this 
data  into  a  service  can  reduce  or  eliminate  the  human  activity.  The  new  Rescue 
21  system  (maritime  911)  is  also  unnecessarily  stovepiped.  It  displays  the  alert 
position  information  on  a  computer  monitor,  but  does  not  provide  the  data  to 
other  systems.  Humans  must  extract  and  distribute  Rescue  21  information. 

b.  Legacy  Monitoring  Systems 

The  following  legacy  monitoring  systems  can  provide  functionality 
in  the  CGC2  SOA: 

•  Automated  Mutual  Assistance  Vessel  Rescue  (AMVER) 
System:  a  voluntary  global  reporting  system  to  provide 
accurate  ship  positions  and  characteristics  for  vessels  near  a 
reported  distress,  and  then  divert  the  best-suited  ship(s)  to 
respond  to  that  distress. 

•  Automated  Identification  System  (AIS):  a  transponder  based 
system  onboard  commercial  vessels  that  broadcasts 
identification  and  position  information. 

•  NLETS  /  NCIC:  a  Department  of  Justice  database  for 
criminal  justice  information  including  photographs  and 
fingerprints. 
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•  Hawkeye:  a  sensor-tracking  system  to  detect,  track,  and 
identify  vessel  traffic. 

•  Lookout  Lists  (LOL):  a  federally  maintained  list  containing 
individuals  subject  to  intense  scrutiny  from  the  US 
government. 

•  Ports  and  Waterways  Safety  System  (PAWSS):  a 

surveillance  and  detection  system  using  remote  sensors  to 
monitor  vessels  operating  in  U.S.  ports  and  waterways. 

•  Rescue  21  Direction  Finder  (R21DF):  a  triangulation 
capability  for  VHF  and  UHF  communications  to  “pin  point”  a 
radio  transmission’s  location. 

•  Search  and  Rescue  Satellite  Aided  Tracking  system 

(SARSAT):  a  satellite  system  for  detecting  a  relaying 

Emergency  Position  Indicating  Radio  Beacons  (EPRIB)  and 
Personal  Locator  Beacons  (PLB)  signals  to  the  appropriate 
Rescue  Coordination  Center. 

•  Ship  Arrival  and  Notification  System  (SANS):  a  database 
populated  with  Advanced  Notice  of  Arrival  information 
provide  by  ships  96  hours  prior  to  entering  U.S.  territorial 
waters. 

•  Vessel  Monitoring  System  (VMS):  and  AIS  system  for 
fishing  vessels. 

•  Vessel  Traffic  Service  (VTS):  a  navigation  information  and 
traffic  organization  system  to  improve  situation  awareness 
for  vessels  operating  in  certain  waterways.  VTS  sensors 
include  cameras,  radars,  and  AIS. 

c.  Monitoring  Services 

The  following  descriptions  provide  the  framework  for  creating 
services  to  meet  the  monitoring  needs  described  above.  The  first  three  were 
written  as  general  monitoring  services  for  reuse  in  other  Coast  Guard  SOAs. 

•  Monitor  Receive-Push:  Accepts  data  being  pushed  from  an 
external  source  (asset,  service,  or  system),  and  then 
forwards  the  data  to  a  consumer. 

•  Monitor  Request-Pull:  Requests  data  from  an  external 
source  (asset,  service,  or  system)  configured  to  respond  to 
requests. 

•  Monitor  T ransmitter:  Sends  internal  events  to  subscribers. 
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•  Weather  Forecast:  Extension  to  the  base  Receive-Push 
service  for  data  from  the  National  Weather  Service. 
Receives  data  forecast  for  a  defined  area. 

•  Environmental  Limits  Monitor:  This  coarse-grained  service 
uses  the  output  from  Weather  Forecast  service  and  a  given 
asset  type.  It  uses  that  data  to  invoke  the  Environmental 
Limits  Check  service.  This  creates  continuous  monitoring  of 
weather  conditions  and  automatically  alerts  the  user  when 
they  exceed  limits. 

•  Rescue21  DF:  Extension  to  the  base  Receive-Push  service 
for  the  Rescue  21  Direction  Finding  system.  This  service  will 
receive  triangulated  positions  from  distress  call  for  a  given 
geographic  area. 

•  eNOAD:  Extension  to  the  base  Request-Pull  service  for  the 
ship  arrival  and  departure  notification  system.  Initial  version 
will  get  updated  information  for  all  vessels  in  a  defined  area 
at  a  defined  frequency.  One  variation  will  only  request 
information  on  one  vessel  and  will  be  linked  to  a  task,  so  that 
vessel  arrival  changes  that  impact  CG  plans  will  get  flagged. 

•  AIS:  Extension  to  the  base  Receive-Push  service  for  the 
Automatic  Identification  System.  This  service  will  receive 
vessel  position  information  for  all  vessels  in  a  defined  area. 

•  Blue  Force  Tracker:  Extension  to  the  base  Receive-Push 
service  to  track  USCG  asset  positions.  This  service  will 
receive  cutter,  boat,  and  aircraft  positions  within  a  defined 
area. 

d.  Monitoring  Summary 

The  Coast  Guard  employs  many  different  stovepipe  systems  to 
monitor  the  maritime  domain.  The  services  in  the  monitoring  functional  area 
expose  the  functionality  and  data  from  those  stovepipes,  allowing  the  SOA  to 
expose  them  for  others  to  access  and  exploit. 

5.  Reporting 

a.  Discussion 

The  reporting  functional  area  operates  at  several  layers.  It 
exchanges  pertinent  data  with  existing  legacy  systems.  It  fuses  information 
collected  by  monitoring  services  into  relevant  data  that  can  be  used  for  planning 
and  tasking.  It  provides  a  means  for  retrieving  information  or  statistics  on 
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resources  expended.  Strategic  planning  and  service  growth  especially  benefit 
from  this  functionality.  Finally,  it  contains  internal  administrative  services 
necessary  to  manage  and  audit  data  entries  for  accuracy  and  process 
adherence. 


For  example,  as  the  CDO  closes  a  SAR  case  the  administrative 
audit  automatically  occurs.  The  audit  will  ensure  the  data  accuracy  and 
correlation  to  all  sources  associated  with  that  entry.  The  audit  will  also  ensure 
that  all  assigned  tasks  or  defined  business  processes  were  completed.  It 
forwards  exceptions  to  information  quality  or  process  adherence  to  the  case 
owner  in  an  exception  report  via  the  messaging  services. 
b.  Legacy  Reporting  Systems 

The  following  legacy  reporting  systems  can  provide  functionality  in 
the  CGC2  SOA: 

•  Abstract  of  Operations  (AOPS):  a  database  for  recording 
Coast  Guard  asset  (cutter,  boat,  aircraft)  employment 
information. 

•  Local  Notice  to  Mariners  (LNM):  a  notification  system  to 
alert  mariners  about  Aids  to  Navigation  (AtoN) 
discrepancies,  outages,  corrections,  and  hazards  to 
navigation. 

•  Marine  Information  for  Safety  and  Law  Enforcement 

(MISLE):  four  integrated  applications  for  recording 

information  about  LE,  Marine  Safety,  SAR,  and  other 
missions. 

•  MHS-OPS:  a  prototype  system  to  create  standardized, 
operational  planning  for  Homeland  Security  operations 
across  the  Chain  of  Command  levels  (HO,  Area,  District, 
Sector,  Unit). 

•  Situation  Report  (SITREP):  a  standard  report  generated  to 
inform  the  Chain  of  Command  about  on-scene  conditions 
and  mission  progress. 

•  Status  Board:  a  display  showing  subordinate  assets 
(cutters,  boats,  aircraft,  teams,  personnel),  their  conditions 
and  current  actions,  typically  done  by  hand  on  a  dry-erase 
board. 
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c.  Reporting  Services 

The  following  descriptions  provide  the  framework  for  creating 
services  to  meet  the  reporting  needs  described  above.  These  three  were  written 
as  general  reporting  services  for  reuse  in  other  Coast  Guard  SOAs: 

•  Report  Request:  Creates  a  request  for  a  report  containing 
specific  information  from  specific  sources. 

•  Report  Aggregator:  Gathers  information  from  other  services 
and  sends  it  to  the  report  generator. 

•  Report  Generator:  Creates  the  report  in  the  requested 
format  and  delivers  it  to  the  requestor. 

•  Database  Query:  Performs  SQL  Data  Manipulation 

Language  Select,  Insert,  Update,  and  Delete  database 
queries. 

•  Case  Auditor:  Verifies  the  process  completion  and 

information  contained  in  an  case  (e.g.,  SAR,  law 
enforcement),  with  detailed  exception  reporting. 

•  Create  Log  Entry:  Creates  an  electronic  log  entry,  can  link 
to  another  specific  service  execution,  creating  an  official 
record  of  Coast  Guard  actions. 

•  Review  Log:  Displays  logs  so  that  users  can  browse  official 
records,  hyper-links  with  logs  allow  users  to  review  when 
and  how  services  were  utilized. 

d.  Reporting  Summary 

The  reporting  services  unlock  the  data  trapped  in  legacy 
stovepipes.  In  doing  this,  they  have  the  potential  to  reach  the  most  users  and 
improve  the  information  quality  they  utilize.  The  ability  to  extract  information 
quickly  and  easily  will  improve  many  users’  effectiveness.  SOA’s  customizable 
nature  will  allow  users  to  configure  the  reporting  services  to  exploit  previously  low 
value  information  in  new  and  powerful  ways. 

E.  QUALITY  ATTRIBUTES 

The  Software  Engineering  Institute  defines  a  quality  attribute  as  “a 
property  of  a  work  product  or  goods  by  which  its  quality  will  be  judged  by  some 
stakeholder  or  stakeholders.  The  quality  attribute  requirements  ...  have  a 
significant  influence  on  the  software  architecture  of  a  system.”  (“Software 
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Architecture  Glossary”)  Quality  attributes  are  the  product  aspects  that 
stakeholders  deem  most  important  to  success,  either  by  delivering  what 
stakeholders  desire  or  avoiding  things  they  can’t  accept.  We  emphasize  the 
following  quality  attributes  for  the  CGC2  SOA:  interoperability,  security,  usability, 
extensibility,  and  scalability.  Other  quality  attributes  may  also  apply,  but  these 
five  are  essential. 

1.  Utility  Tree 

Utility  trees  provide  a  top-down,  structured  method  for  generating 
scenarios  to  define  quality  attributes  concretely.  The  utility  tree’s  nodes  show 
important  quality  goals  and  the  leaves  hold  scenarios  exemplifying  those  goals. 
We  have  produced  a  utility  tree  for  the  CGC2  SOA.  Figure  8  below  shows  the 
first  three  levels.  This  tree  stops  at  the  quality  attribute  refinement  level,  before 
showing  the  specific  quality  attribute  scenarios.  Individual  quality  attribute 
descriptions  later  in  this  section  carry  the  process  through  and  depict  detailed 
scenarios.  We’ve  numbered  the  quality  attributes  using  a  dot  notation,  for 
example  numbering  “Security  -  ensure  releasability”  as  2.4.  The  trees  show 
these  numbers  in  blue. 

A  utility  tree  also  encourages  stakeholders  to  prioritize  the  quality  attribute 
requirements  in  two  ways:  “(1 )  by  the  importance  of  each  scenario  to  the  success 
of  the  system  and  (2)  by  the  degree  of  difficulty  posed  by  the  achievement  of  the 
scenario,  in  the  estimation  of  the  architect.”  (Clements,  Kazman,  Klein  55) 
Relative  rankings  High  (H),  Medium  (M)  and  Low  (L)  indicate  the  priorities  we 
assigned.  The  scenarios  marked  (H,  H)  become  the  focus  of  architecture 
development  effort  because  they  represent  current  and  future  driving  forces  on 
the  architecture.  We  indicate  our  priorities  above  each  quality  attribute  scenario. 
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Figure  8.  Utility  Tree  (top  level) 
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2.  Quality  Attribute  -  Interoperability  (1 .0.0) 

Interoperability  assures  the  communicating  entities’  can  share  specific 
information  and  operate  on  it  according  to  an  agreed-upon  operational 
semantics.  (O’Brien,  Bass,  Merson  4)  The  scenarios  on  the  right  side  of  Figure 
9  illustrate  our  SOA’s  unique  interoperability  requirements. 


Figure  9.  Utility  Tree  -  Interoperability 


3.  Quality  Attribute  -  Security  (2.0.0) 

Security  has  many  different  aspects,  but  generally  exists  when  users, 
applications,  and  services  can  only  perform  authorized  actions.  The  following 
four  principles  are  broadly  used  to  define  computer  security: 

•  Confidentiality  -  only  authorized  subjects  can  access  the 
information  or  service. 

•  Authenticity  -  verification  that  the  indicated  author/sender  is  the 
one  responsible  for  the  information. 

•  Integrity  -  information  is  not  corrupted. 

•  Non-repudiation  -  a  message  or  action  cannot  later  be  denied 
by  any  participant. 

(O’Brien,  Bass,  Merson  12) 

The  scenarios  on  the  right  side  of  Figure  10  illustrate  our  SOA’s  unique 
security  requirements. 
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Figure  10.  Utility  Tree  -  Security 

4.  Quality  Attribute  -  Usability  (3.0.0) 

Usability  measures  the  quality  of  a  user’s  experience  while  interacting  with 
information  or  services.  (O’Brien,  Bass,  Merson  11)  A  system  that  does  what 
the  user  wants,  when  they  want  it  done  has  high  usability.  The  scenarios  on  the 
right  side  of  Figure  1 1  illustrate  our  SOA’s  unique  usability  requirements. 
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Figure  1 1 .  Utility  T ree  -  Usability 


5.  Quality  Attribute  -  Extensibility  (4.0.0) 

Extensibility  provides  the  ability  to  add  new  features  or  components  to  the 
existing  services  without  affecting  other  services  or  parts  of  the  system. 
(O’Brien,  Bass,  Merson  17)  Extensibility  requires  the  architecture  to  consider 
future  growth  and  adapt  to  a  changing  environment.  The  scenarios  on  the  right 
side  of  Figure  12  illustrate  our  SOA’s  extensibility  requirements. 
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Figure  1 2.  Utility  T ree  -  Extensibility 


6.  Quality  Attribute  -  Scalability  (5.0.0) 

Scalability  provides  the  ability  to  function  well  (without  degradation  of  other 
quality  attributes)  when  the  system  increases  in  size  or  volume  in  order  to  meet 
users’  needs.  (O’Brien,  Bass,  Merson  16)  Designing  for  scalability  requires 
understanding  the  bottlenecks  in  the  system  and  then  applying  a  horizontal 
(distributing  work  to  other  machines)  or  vertical  (upgrade  to  more  powerful 
machine)  solution.  The  scenarios  on  the  right  side  of  Figure  13  illustrate  our 
SOA’s  unique  scalability  requirements. 
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Figure  13.  Utility  T ree  -  Scalability 


7.  Operational  Examples 

Table  2  below  contains  nine  vignettes  that  demonstrate  the  CGC2  SOA’s 
desired  aspects.  The  right  column  links  each  vignette  to  the  applicable  scenarios 
from  the  utility  trees  above  using  the  dot  notation.  This  table  shows  the 
relationships  between  Coast  Guard  missions  and  the  architecture’s  quality 
attributes. 
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Vignettes  QA  Scenario 


Marine  Safety 

[Search  &  Rescue]  A  cruise  ship  carrying  1000  passengers  catches  fire  100  1.2.1 

miles  off  the  coast  of  North  Carolina.  Aircraft  and  cutters  from  two  Coast  3.1.1 

Guard  districts  respond.  Ten  level  1  and  level  2  trauma  centers  are  contacted.  3.3.1 
AMVER  identifies  10  vessels  in  the  vicinity,  they  are  contacted  and  assist.  3.4.1 

[Boating  Safety]  The  Coast  Guard  implements  a  Safe  Boating  portal  for  the  1.1.2 
public.  It  provides  weather  forecasts,  notice  to  mariners  information,  and  the  3.4.1 
ability  to  create  and  file  a  Float  Plan.  This  web  site  does  not  break  under  4.2.1 

heavy  seasonal  load  (e.g.,  summer  holiday  weekends).  The  information  5.1.1 

entered  is  easily  shared  with  local  units  and  emergency  response  agencies. _ 5.4.1 


National  Defense 

[Homeland  Security]  Intel  from  a  new  data  source  detects  a  potential  threat  on 
a  cargo  container  bound  for  the  U.S.  The  vessel  is  boarded  off  shore  and  the 
container  is  found  carrying  hundreds  of  illegal  weapons.  This  event  involves 
the  Coast  Guard,  Customs  and  local  port  authority. 

Maritime  Security 


[Drug  Enforcement]  A  WMEC  on  a  regularly  scheduled  LE  patrol  in  the  1.1.1 
Caribbean  Sea  boards  a  foreign  flagged  high  interest  vessel  and  discovers  2.1.1 

3000  pounds  of  cocaine.  The  U.S.  State  Department,  U.S.  Department  of  2.2.1 

Justice,  and  the  foreign  government  are  also  involved.  2.3.2 

[LMR]  A  WHEC  reports  dozens  of  Russian  vessels  illegally  fishing  in  the  2.2.1 
“Donut  Hole”  in  Alaska.  The  WHEC  CO  reports  that  he  met  with  strong  2.3.1 

resistance  while  attempting  to  board  one  of  the  vessels  and  he  is  asking  for  3.1.1 

support.  3.2.1 

[LMR]  A  short  duration  seasonal  fishery  opens  requiring  increased  law  1.1.2 
enforcement  effort  and  SAR  response  readiness.  This  day  or  week  long  event  1 .2.1 
involves  the  National  Marine  Fisheries  Service,  state  Fish  and  Wildlife  5.1.1 

agencies,  and  National  Oceanographic  and  Atmospheric  Agency  attorneys. _ 5.2.1 


Maritime  Mobility 

[ATON]  A  hurricane  off  the  east  coast  forces  over  100  buoys  off  station  and  1.2.1 

damages  hundreds  more  fixed  aids.  ATON  assets  from  multiple  districts  3.1.1 

respond  to  survey  the  waterways  and  reposition  the  aids.  5.2.1 

5.3.1 

[VTS]  A  new  Vessel  Traffic  Service  is  established  in  a  large  commercial  port.  5.1.1 

This  new  unit  will  require  50  new  users,  track  over  100  vessels  a  day,  and  will  5.2.1 

exchange  information  with  two  port  authorities,  the  pilots,  and  50  companies. _ 5.4.1 


Protection  of  Natural  Resources 

[Oil  Spill]  A  super  tanker  runs  aground  in  the  Straits  of  Juan  De  Fuca  spilling  1.1.1 

millions  of  gallons  of  crude  oil,  jeopardizing  hundreds  of  miles  of  U.S.  and  1.1.2 

Canadian  coastline.  The  response  effort  includes  multiple  U.S.  and  Canadian  3.3.1 
Coast  Guard  assets,  as  well  as  federal  and  local  government  agencies. _ 4.1.1 


Table  2.  Operational  Examples  and  Corresponding  Quality  Attributes 


1.1.1 

1.1.2 

2.1.1 

4.1.1 
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F.  CONCEPTUAL  DATA  MODEL  (CDM) 

This  section  outlines  the  CGC2  SOA  data  model.  The  actual  CDM 
process  will  be  “a  serious  data  modeling  exercise  that  typically  requires  the  input 
of  highly  experienced  analysts  and  architects.  The  end  result  is  a  set  of  custom 
standards  for  the  enterprise.”  (Gabriel)  As  such,  the  conceptual  diagrams 
presented  here  show  only  a  small  portion  of  the  full  model  required  to  implement 
a  functional  system.  We  chose  to  focus  on  the  Planning  and  Tasking  functional 
areas  because  they  provide  examples  most  readers  will  easily  understand.  At 
this  point  it’s  important  to  clarify  our  terminology  so  we  don’t  confuse  the  terms 
planning  and  tasking.  In  this  chapter’s  “Functional  Areas”  section,  planning  and 
tasking  are  verbs,  or  actions  the  services  perform.  In  this  section,  planning  and 
tasking  are  nouns,  or  concepts  represented  by  the  data  models  shown.  Although 
we  present  incomplete  data  models,  they  provide  concrete  data  organization 
examples  within  the  CGC2  SOA  system.  The  figures  below  show  XML  schema 
diagrams.  The  rectangles  represent  individual  CDM  elements  (e.g.,  Asset),  but 
they  do  not  contain  specific  data  from  the  example  (e.g.,  USCGC  RUSH,  a  high 
endurance  Coast  Guard  cutter). 

1.  Planning  Element 

A  plan  includes  elements  for  the  commander’s  intent,  the  assets 
employed,  the  operating  area,  the  plan  type,  and  the  target  objects.  The 
PlanType  element  contains  related  missions,  tasks,  and  other  plans.  This  data 
model  works  for  a  strategic  plan  and  its  supporting  operational  plans.  Figure  14 
shows  a  conceptual  view  of  the  Plan  element. 


58 


Plan  |B - (d)b - (»— «)E 


Commariderslntent 


Assets 


B - (HT)b - (»— *)E}| - 


Type 


—  Amount 


OpArca 


PlanTypc 


0 — 


Plan 

Mission 

\ _ 

Task 

Target  B - (□~)B - (»**«)b-| —  Type 


VuchMoreH  ere 


Figure  14.  Data  Model  -  Planning  Element 


To  illustrate  the  data  model,  consider  the  following  example.  District  14 
creates  a  fisheries  enforcement  operations  plan.  In  addition  to  the  typical 
operations  plan  information  (why,  who,  how,  what,  when,  where)  it  includes 
USCGC  RUSH’S  and  Air  Station  Barbers  Point’s  missions  and  tasks.  In  this 
conceptual  data  model,  a  task  can  occur  as  a  Plan  element  or  as  a  Mission 
element  contained  in  a  plan.  In  our  examples,  all  tasks  are  Missions  elements. 
We  have  no  Plan-level  tasks.  Missions  and  tasks  will  be  exemplified  in  the 
following  sections. 

2.  Mission  Element 

When  an  asset  carries  out  a  mission,  it  performs  multiple  tasks.  The  CDM 
Mission  element’s  structure  represents  this  by  grouping  tasks  performed  to 
support  the  mission.  Figure  15  shows  a  conceptual  view  of  the  Mission  element. 
While  this  conceptual  view  lacks  detail,  additional  elements  will  be  added  to 
include  appropriate  amplifying  details  when  the  Coast  Guard  creates  the  actual 
CDM. 
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Figure  15.  Data  Model  -  Mission  Element 


In  our  example,  Air  Station  Barbers  Point’s  mission  contains  tasks  for 
individual  HC-130  surveillance  flights.  USCGC  RUSH’S  mission  includes 
patrolling  a  large  area,  employing  its  sensors  and  embarked  HH-65  helicopter  to 
locate  fishing  vessels.  When  an  asset  locates  a  fishing  vessels,  USCGC  RUSH 
will  intercept  them  and  deploy  its  small  boat,  which  will  transport  the  boarding 
team.  The  team  will  board  the  vessels  and  enforce  all  applicable  U.S.  laws, 
regulations,  and  treaties.  All  four  assets  (e.g.,  RUSH,  HH-65,  small  boat, 
boarding  team)  carry  out  distinct  tasks  related  to  the  cutter’s  mission.  The 
District  14  operations  plan  contains  both  the  Air  Station’s  and  cutter’s  missions. 

3.  Task  Element 

The  Task  element’s  structure  provides  the  what,  when,  where  and  other 
relevant  details  about  a  task.  Figure  16  shows  a  conceptual  view  of  the  Task 
element. 
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Figure  16. 


Data  Model  -  Task  Element 


Continuing  our  example,  we  create  a  task  for  each  HC-130  surveillance 
flight,  each  HH-65  flight,  and  multiple  tasks  for  USCGC  RUSH’S  patrol.  The 
target  in  the  Task  element  can  be  either  a  general  target  type  (e.g.,  fishing 
vessels)  or  a  specific  object  (e.g.,  F/V  BIG  KAHUNA)  represented  by  the  Target 
element  shown  in  Section  F.5.  below.  During  a  HH-65  task  the  helicopter  locates 
F/V  BIG  KAHUNA  15  miles  from  USCGC  RUSH.  USCGC  RUSH  generates  a 
task  to  intercept  the  vessel,  a  task  for  the  small  boat,  and  a  task  for  the  boarding 
team. 

4.  Asset  Element 

Assets  include  the  aircraft,  cutters,  boats,  vehicles,  teams,  and  individuals 
that  perform  Coast  Guard  missions.  The  Asset  element  models  an  asset’s 
capabilities  (e.g.,  speed,  range)  and  limitations  (e.g.,  weather,  endurance). 
Figure  17  shows  a  conceptual  view  of  the  Asset  element.  Assets  in  our  example 
include  the  USCGC  RUSH,  HH-65,  small  boats,  boarding  teams,  and  HC-130. 
Note  that  the  data  element  below  can  easily  incorporate  vehicles  and  vessels 
from  local  police,  fire  departments,  and  other  emergency  response  organizations. 
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Figure  17. 
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Data  Model  -  Asset  Element 


5.  Target  Element 

Targets  are  things  we  want  to  track  or  find.  Targets  exist  at  two  levels  in 
the  CDM.  The  Plan  and  Task  elements  utilize  general  target  types  (e.g.,  fishing 
vessels).  Tasks  can  also  contain  information  about  a  specific  object  (e.g.,  F/V 
BIG  KAHUNA)  with  details  that  enable  an  asset  to  track  or  find  it.  The  CDM’s 
Target  element  contains  the  needed  details.  Figure  18  shows  a  conceptual  view 
of  the  Target  element. 


Figure  1 8.  Data  Model  -  Target  Element 
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6.  CDM  Conclusion 

A  complete  CGC2  SOA  data  model  capturing  all  five  functional  areas 
obviously  requires  much  more  detail  and  many  more  elements.  As  stated  earlier, 
creating  a  CDM  requires  experienced  and  skilled  analysts  and  architects.  A 
complete  CDM  exceeds  this  thesis’  scope.  We  have  introduced  a  basic 
framework  that  supports  our  command  and  control  functional  areas.  The  Coast 
Guard  has  already  begun  modeling  data  elements  in  existing  systems  with  the 
Enterprise  Data  Catalogue  project.  While  this  effort  will  not  produce  a  CDM,  it 
moves  us  in  the  right  direction  and  will  provide  supporting  documentation  to 
create  a  sound  command  and  control  CDM  when  the  time  comes. 

7.  Information  Exchange  Models 

The  previous  sections  have  described  an  information  sharing  data  model 
within  the  Coast  Guard.  However,  we  also  need  to  share  information  with 
multiple  federal,  state,  local,  and  foreign  government  agencies.  That  information 
sharing  requires  a  different  data  model.  Communities  of  Interest  (COI)  are 
collaborative  groups  that  create  an  accepted  information  exchange  vocabulary 
relating  their  shared  goals,  interests,  and  objectives.  COI  data  models  are  often 
called  information  exchange  models.  Two  notable  command  and  control 
information  exchange  models  include: 

•  Joint  Consultation  Command  &  Control  Information  Exchange  Data 
Model  (JC3IEDM)  -  decade-long  NATO  endeavor  to  create  a 
command  and  control  information  exchange  model. 

•  National  Information  Exchange  Model  (NIEM)  -  U.S.  federal 
government  project  to  create  “enterprise-wide  information  exchange 
standards  and  processes  that  can  enable  jurisdictions  to  effectively 
share  critical  information  in  emergency  situations,  as  well  as  support 
the  day-to-day  operations  of  agencies  throughout  the  nation.” 
( www.niem.gov ) 

COI  data  models  rarely  function  as  the  CDM  within  any  one  organization, 

since  they  exist  to  exchange  information  between  community  members.  They 
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are  not  built  to  meet  any  one  member’s  individual  needs.  This  is  true  of 
JC3IEDM  and  NIEM.  Neither  model  meets  the  Coast  Guard’s  needs  for  internal 
use,  because  they  don’t  meet  our  unique  command  and  control  needs. 
However,  we  must  consider  widely  accepted  COI  models  like  JC3IEDM  and 
NIEM  when  creating  our  CDM.  The  ability  to  quickly  and  accurately  translate 
information  between  them  and  our  CDM  will  provide  unprecedented  data  sharing 
with  other  agencies. 

8.  Maritime  Information  Exchange  Model  (MIEM) 

A  COI  developed  data  model  occasionally  does  meet  an  organization’s 
content,  scope,  and  complexity  needs.  When  that  happens,  the  data  model  can 
be  utilized  within  the  organization’s  larger  CDM.  The  Navy’s  Comprehensive 
Maritime  Awareness  Joint  Capability  Technology  Demonstration  (CMA  JCTD) 
produced  one  such  model.  The  Maritime  Information  Exchange  Model  logically 
groups  data  by  epochs  in  the  vessel’s  history.  This  links  sensor  data  for  vessel 
positions  and  all  available  data  about  cargo,  people,  companies,  and  facilities 
associated  with  the  vessel.  Should  the  MIEM  become  the  standard  for  Maritime 
Domain  Awareness  data  sharing,  it  could  easily  replace  the  Target  element  in 
our  CDM’s  Task.  This  would  enable  the  CGC2  SOA  to  accept  a  Maritime  Object 
from  an  intelligence  fusion  system  and  pass  it  on  to  an  asset  in  a  Task.  A  CGC2 
SOA  Case  that  contained  both  the  Coast  Guard  boarding  results  and  the  related 
Maritime  Object  would  provide  solid  evidence  for  our  law  enforcement  action. 
The  Coast  Guard  could  forward  it  on  to  the  Department  of  Homeland  Security  or 
Department  of  Justice  for  criminal  prosecution.  Because  those  agencies  IT 
systems  can  accept  MIEM  formatted  data,  the  attorneys  can  automatically  utilize 
the  case  file.  This  semantic  interoperability  perfectly  demonstrates  the  powerful 
combination  of  SOA  and  shared  data  models.  Figure  19  shows  the  MIEM’s  base 
element,  the  MaritimeObject. 
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Figure  19.  MIEM  -  Maritime  Object 


G.  PRODUCT  LINE  ARCHITECTURE  FOR  COMPOSITE  APPLICATIONS 

1.  Composite  Applications 

Composite  applications  interact  with  users  by  providing  the  necessary 
user-level  services  to  create  an  SOA  user  interface.  We  compose  applications 
by  coupling  several  different  services,  data  stores,  and  user  interfaces  using 
standardized  message  layers.  Loosely  coupled  frameworks  allow  individual 
nodes  in  a  distributed  system  to  change  without  affecting  or  requiring  change  in 
any  other  part  of  the  system.  The  composite  application’s  components  can  be 
mixed  and  matched,  like  Lego  blocks,  allowing  developers  to  create  many 
different  applications  with  relatively  few  services.  Figure  20  shows  a  composite 
application  for  command  and  control  with  a  customization  layer  to  provide  each 
user  with  the  functionality  and  presentation  he  or  she  wants. 
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Figure  20. 


Example  Composite  Application 


2.  Product  Line  Architectures 

As  the  Coast  Guard  follows  the  Commandant’s  mandate  to  shift  our 
information  technology  infrastructure  to  SOA,  we  will  make  many  different 
composite  application  variations.  The  Coast  Guard  should  obviously  develop 
them  with  an  adaptive  and  efficient  (faster,  cheaper,  more  reuse)  method. 
Product  Line  Architectures  provide  such  a  method.  A  PLA  helps  developers 
implement  a  family  of  related  software  products  that  address  a  variety  of  similar 
application  requirements  by  composing  generic  reusable  components.  The  PLA 
defines  how  the  components  function  and  interact  to  create  the  required  product. 
The  Software  Engineering  Institute  defines  a  PLA-based  family  of  products  this 
way: 

A  set  of  software-intensive  systems  sharing  a  common,  managed 
set  of  features  that  satisfy  the  specific  needs  of  a  particular  market 
segment  or  mission  and  that  are  developed  from  a  common  set  of 
reusable  core  assets  in  a  prescribed  way.  (“Software  Architecture 
Glossary”) 

Most  successful  PLAs  generalize  and  evolve  from  successful  products, 
and  therefore  the  Coast  Guard  won’t  be  in  a  position  to  create  a  credible  PLA 
until  after  some  composite  applications  are  built.  Once  the  first  few  composite 
applications  exist,  we  can  identify  the  necessary  architecture  and  understand 
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how  to  generalize  specific  implementations  into  reusable  frameworks  and 
components.  We  can  then  begin  to  consider  how  many  valuable  components  we 
have,  where  we  find  them,  how  much  to  invest  in  them,  and  where  to  start.  We 
need  to  think  about  our  product  line  as  a  portfolio  of  assets,  with  each  service  or 
component  evaluated  based  on  its  individual  performance  and  importance  to  the 
product  line  as  a  whole.  We  want  to  work  intelligently  by  focusing  on  areas  of 
greatest  value  first,  to  discover  and  exploit  the  PLA  early.  The  goal  is  to  deliver 
big  value  and  reap  big  rewards  by  reapplying  lessons  learned  and  reusing 
components  extracted  from  previous  applications  and  PLA  endeavors.  We  will 
focus  on  concentrating  in  depth  on  one  area,  iterating  to  develop  one  PLA  and 
systematically  reuse  components.  Figure  21  shows  a  PLA  for  command  and 
control,  with  services  as  the  reusable  components. 
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Figure  21 .  Command  and  Control  SOA  as  PLA 


3.  Mashability 

The  purple  “customization”  adaptors  in  Figure  20  represents  many 
different  options  for  tailoring  each  component.  While  many  issues  arise  in 
creating  customizable  components,  we  find  one  aspect  critical  for  each 
component.  We  call  this  aspect  mashability1 .  Each  component  must  be 
mashable  in  at  least  three  dimensions;  human-computer  interface,  world  model, 
and  C2  functions. 

1  The  term  mashup  describes  a  web  page  or  application  that  combines  data  from  two  or 
more  external  sources.  We  use  the  term  mashability  to  describe  a  component’s  ability  to  be 
mashed,  or  combined,  with  other  components. 
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•  Human-Computer  Interface:  A  human  user  ultimately  receives 
information  from  a  component.  This  dimension  determines  the 
methods  for  physical  display  characteristics  (size,  position)  and  the 
different  options  for  combining  its  output  with  that  of  other 
components.  Most  readers  familiar  with  mashups  only  think  of  this 
aspect  of  mashability.  A  nautical  chart  from  one  source,  weather 
from  another  component,  and  AIS  data  from  a  third  mash  easily  on 
a  graphical  geographic  display.  These  three  merge  to  present  the 
user  with  new  and  meaningful  information. 

•  World  Model:  A  “world  model”  represents  an  organization’s 
situation  awareness.  It  represents  our  best  understanding  of  what’s 
going  on,  where,  why,  and  how.  This  model  is  the  basis  for  efficient 
thought,  a  more  extensive  version  of  the  OODA  loop  (Hayes-Roth 
Hyper-beings  59).  It  maintains  the  environment’s  state  in  three 
time  regions;  past,  present,  and  future.  It  also  maintains  data  at 
different  levels  of  abstraction  and  aggregation,  as  needed  for 
decision-making  by  officers  responsible  for  vastly  different 
geographic  and  temporal  scopes.  So  each  component  operates  on 
data  from  some  select  portion  of  the  organization’s  world  model. 
Each  component  must  describe  how  it  mashes  its  portion  of  the 
world  model  with  those  being  used  by  the  other  components  in  the 
same  application.  For  example  the  previously  described  GUI  with 
weather,  chart,  and  AIS  data  might  have  a  slide  bar  that  represents 
time.  As  the  user  drags  the  slider  forward  the  AIS  tracks  and 
weather  data  step  forward  through  time,  reflecting  each 
component’s  state  at  each  future  time  point.  The  components’ 
world  model  mashability  makes  merging  components’  beliefs 
possible. 

•  C2  Functionality:  Each  component  performs  one  or  more  functions 
of  the  Efficient  Thought  superior  decision  making  loop.  These 
functions  access  and  modify  a  user’s  world  model.  The 
components’  functionalities  must  also  be  mashable.  For  example  a 
component  that  performs  some  “assess  situation”  function  must 
easily  mash  with  other  components  that  produce  sensor  data 
“observations.”  In  this  way,  composite  applications  can  assemble 
process  chains  from  individual  components  and  their  outputs. 

4.  Conclusion 

The  Coast  Guard  will  need  to  improve  continuously  its  Product  Line 

Architecture  based  on  each  iteration’s  successes  or  failures.  Ultimately,  we  will 

develop  services  in  other  domains  as  well,  and  then  we  will  want  to  create 

composite  applications  for  human  resources,  logistics,  and  financial 

management,  to  name  a  few.  We’ll  learn  lessons  about  the  architecture  and  its 
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components  as  we  build  applications.  Our  race  into  the  future  depends  on  our 
ability  to  learn  quickly  and  exploit  those  lessons  effectively.  The  next  chapter 
describes  our  implementation  plan.  It  proposes  a  two-loop  method  for 
continuous,  incremental  improvement. 
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IV.  IMPLEMENTATION  PLAN 


A.  INTRODUCTION 

This  chapter  provides  the  response  to  our  second  thesis  question,  “What 
is  the  optimal  implementation  plan  for  this  CGC2  SOA?”  Unfortunately,  a  typical 
government  approach  to  design  an  architecture  and  develop  systems  that  meet 
our  command  and  control  needs  will  likely  fail,  as  do  most  large-scale  information 
technology  projects.  These  “big  bang”  projects  have  decades-long  timelines  and 
usually  fail  because  they  base  their  architecture  on  requirements  collected  once, 
during  a  prolonged  process  at  the  project’s  inception.  We  disagree  with  the  “big 
bang”  approach.  We  expect  that  our  needs  will  change  over  time,  and 
technology  will  continue  its  dramatic  advance.  In  order  to  accommodate  our 
evolving  needs  and  capitalize  on  the  latest  technology,  we  think  that  the  Coast 
Guard  should  avoid  creating  the  CGC2  SOA  as  a  “big  bang”  project. 

In  addition  to  “big  bang”  projects,  two  other  common  approaches  are  used 
to  implement  systems.  Figure  22  shows  their  theoretical  ability  to  provide 
capability  over  time.  We  call  the  first  alternative  “Build  it  Now”  because  it  skims 
through  the  requirements  collection  and  architecture  definition  activities  and 
almost  immediately  begins  building  things.  We  call  the  second  alternative 
“Incremental  Evolutionary”  because  it  aspires  to  deliver  value  while  defining  the 
architecture  in  response  to  ever  changing  needs.  Section  B  describes  this 
method  in  greater  detail. 
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We  recommend  the  “Incremental  Evolutionary”  approach  as  the  best 
method  to  implement  the  CGC2  SOA.  It  recognizes  the  constantly  changing 
nature  of  both  the  problem  and  required  solution  and  then  evolves  accordingly.  It 
also  supports  horizontal  integration,  across  Coast  Guard  mission  areas,  and 
resists  creating  vertical  stovepipes.  Both  the  “Big  Bang”  and  “Build  it  Now” 
methods  fail  to  deliver  capability  as  theorized.  The  “Big  Bang”  method  expends 
precious  time  and  resources  defining  a  problem  and  potential  solution,  ignoring 
the  fact  that  both  the  problem  and  technology  available  to  solve  it  are  constantly 
changing.  The  “Build  it  Now”  approach  fails  because  the  developers  fail  to 
properly  consider  the  long-term  and  widespread  impacts  their  early  decisions 
have  on  the  eventual  system. 

Figure  23  contrasts  the  theoretical  achievements  of  these  various 
approaches  with  the  results  they  usually  attain  in  actuality.  The  “Big  Bang” 
systems  usually  fail,  thus  delivering  no  value.  The  “Build  It  Now”  approaches 
achieve  diminishing  returns  over  time  and  eventually  require  a  start-over.  An 
“Incremental  Evolutionary”  approach  on  the  other  hand,  continually  plans  for, 
adapts  to,  and  exploits  predictable  advances  in  technology  to  deliver  more  value 
and  what  Kurzweil  calls  “accelerating  returns.”  (Kurzweil  31-35) 


Therefore,  we  must  adopt  a  flexible,  rapid,  and  incremental 
implementation  process  that  delivers  some  immediate  value  to  users.  To  keep 
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pace  with  our  changing  needs  and  advancing  technology,  the  development 
cycles  must  produce  software  services  or  applications  every  six  to  twelve 
months.  We  must  also  utilize  a  process  that  will  evolve  the  architecture  as  we 
gain  experience  with  the  service  oriented  methodology.  We  describe  our 
incremental  implementation  method  in  Section  B,  followed  by  a  proposed 
organizational  alignment  in  Section  C.  Section  D  summarizes  several  SOA  “best 
practices”  and  “worst  practices”  from  the  information  technology  industry  and 
Section  E  addresses  the  impacts  SOA  has  on  quality  attributes.  The  answer  to 
our  second  thesis  question  provides  a  sound  approach  that  outlines  key  activities 
required  to  create  the  CGC2  SOA  successfully. 

B.  DASH-CREIGH  IDeA  METHOD 

1.  Introduction 

We  designed  the  Incremental  Development  Approach  (IDeA)  to  improve 
the  Coast  Guard’s  ability  to  implement  the  SOA  successfully.  Our  method  is 
based  on  agile  software  development  practices  that  minimize  risk  by  producing 
software  in  short  iterations  with  clearly  defined  scope.  IDeA  focuses  on 
continuous  improvement  of  the  architecture,  software  components,  and  the 
implementation  process  itself.  IDeA  comprises  two  connected  loops,  the 
Architecture  Loop  and  the  Service  Development  Loop  (SDL).  The  Architecture 
Loop  designs,  evaluates,  and  evolves  the  SOA  at  the  same  time  that  the 
components  (services)  are  created,  deployed  and  assessed.  The  SDL  produces 
and  improves  the  actual  components.  We  propose  this  approach  to  implement 
the  Command  and  Control  SOA  described  in  Chapter  III,  but  we  purposely  made 
it  general  enough  for  any  SOA  implementation. 

2.  Architecture  Loop 

The  Architecture  Loop  begins  with  the  vision,  technical  strategies,  and 

concepts  that  influence  the  architecture.  Each  stakeholder  brings  his  or  her  own 

ideas  about  the  architecture’s  design  and  functions.  The  architects  and 

implementers  need  to  understand  SOA’s  strengths  and  weakness  when 

designing  and  building  the  CGC2  SOA.  Equally  important,  they  must  accept  the 

fundamental  change  from  building  vertical  stovepipe  information  systems  to 
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horizontally  integrated  ones.  SOA’s  modular  horizontal  integration  unlocks  the 
functionality  and  data  trapped  inside  stovepipe  systems  and  allows  imaginative 
Coast  Guard  personnel  to  create  new  uses  from  existing  components.  The  cloud 
at  the  top  of  Figure  24  graphically  represents  this  “vision.”  The  Architecture  Loop 
continues  with  four  sequential  steps  and  their  outputs.  The  first  two  steps 
incrementally  produce  the  services;  the  final  two  steps  provide  continuous 
improvement.  The  Architecture  Loop’s  steps  and  outputs  are  listed  in  Table  3. 


Steps 

Outputs 

Design  SOA 

Set  of  Services 

Build  One  Component 

Functioning  Component 

Re-evaluate 

Revised  Business  Processes  and 

Revised  Technical  Processes 

Adjust  Vision,  Strategy,  and  Concepts 

Revised  Vision,  Strategy,  and  Concepts 

Table  3.  IDeA  Architecture  Loop  -  Steps  and  Outputs 


Design  SOA  -  The  design  process  combines  the  stakeholders’  visions, 
technical  strategies,  and  desired  end  states.  It  produces  many  concepts 
represented  in  various  forms:  utility  trees  of  quality  attributes  and  scenarios,  line 
diagrams  of  components  and  the  relationships  between  them,  and  lists  of 
required  technical  standards.  Ultimately,  service  designers  transform  these 
concepts  into  distinct  services  with  detailed  descriptions  of  their  functionality, 
interfaces,  and  interactions  (with  external  systems  and  other  services). 

Build  One  Component  -  This  step  represents  the  Service  Development 
Loop  (SDL)  that  will  be  described  in  the  following  section.  In  this  step, 
developers  convert  a  description  into  a  functioning  service.  This  incremental 
SOA  implementation  generates  test  cases,  metrics  and  measured  qualities  to 
verify  that  the  service  performs  as  described. 

Integrate  New  Component  Into  SOA  -  This  step  integrates  the  newly 
created  service  into  the  SOA.  Existing  workflows  and  processes  may  need 
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modification  to  incorporate  the  new  component  appropriately  and  maximize  the 
benefits  it  provides. 

Re-evaluate  -  This  step  in  the  Architecture  Loop  exists  to  capture  lessons 
learned  from  building  the  last  service.  It  begins  the  continuous  improvement 
effort  by  assessing  the  new  service’s  technical  and  business  usefulness,  or 
“operational  performance.”  The  technical  review  compares  quality  attribute 
levels  (e.g.,  security,  reliability,  scalability,  etc.)  in  the  new  service  to  those 
sought  in  the  architecture.  The  SDL  also  evaluates  each  service.  However,  the 
SDL  review  focuses  on  the  service’s  internal  workings.  In  contrast,  this  technical 
review  identifies  architectural  changes  necessary  to  rectify  problems  and  prevent 
similar  shortcomings  in  future  loops.  The  business  review  looks  at  the  service’s 
functionality  and  outputs  to  determine  its  fit  within  the  workflow.  This  identifies 
modifications  to  the  new  service,  and  existing  services,  to  improve  overall 
performance. 

Adjust  Concepts  -  This  step  takes  what  you  have  learned  and  revises  the 
concepts,  vision,  and  technical  strategy  that  shape  the  architecture.  We  expect 
each  pass  through  the  Architecture  Loop  will  bring  improved  understanding  of  the 
architecture  and  implemented  services.  Stakeholders  will  have  first-hand 
experience  about  what  can  be  accomplished  and  how.  Their  improved 
understanding  will  likely  lead  to  architectural  changes,  which  restarts  the  loop  at 
the  “Design  SOA”  step. 
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Vision  &  Technical  Strategy 
(concepts  of  desired  state) 


3.  Service  Development  Loop  (SDL) 

The  SDL  begins  by  describing  why  and  how  to  invoke  the  service.  The 
developers  must  clearly  understand  the  contexts  in  which  the  service  operates  to 
implement  it  effectively.  This  goal  and  context  awareness  describes  the  “voice  of 
the  customer,”  and  the  cloud  at  the  top  of  Figure  25  graphically  represents  it. 
Table  4  lists  the  SDL  steps. 


Steps 

Outputs 

Identify  Functionality  and 

Quality  Attributes 

Unconstrained  list  of  Functions  and  Quality 
Attributes 

Develop  Scenarios  for  Quality 
Attributes  and  Functionality 

List  of  brief  scenarios 

Prioritize  and  Select 

List  of  Quality  Attributes  and  Functionalities  to  be 
implemented  during  current  iteration 

Identify  External  Interactions  and 
Interfaces 

Service  Interface  Descriptions 

Identify  Measures 

List  of  metrics  and  success  thresholds 

Develop  and  Deploy  Service 
(return  to  Architecture  Loop) 

Working  service  that  performs  required 
functionality  with  proper  quality  attributes 

Measure  and  Evaluate 

Service  performance  areas  for  future  development 
and  revision 

Review  and  Adjust  Process 

Process  improvements  based  on  lessons  learned 

Table  4.  IDeA  Service  Development  Loop  -  Steps  and  Outputs 


This  loop  contains  eight  steps,  with  a  split  after  the  “Develop  and  Deploy 
Service”  step.  To  continue  overall  system  development,  you  return  to  the 
Architecture  Loop  and  continue  that  process  with  the  newly  created  service, 
proceeding  to  develop  the  next  component.  The  SDL  moves  on  to  measure, 
evaluate,  improve,  and  evolve  the  current  service  as  necessary.  It  also  identifies 
ways  to  adjust  the  SDL  process  itself. 
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Enter  from  Architecture  Loop  with 
Service  Description  &  System  Context 
(voice  of  the  customer) 
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IDeA  Service  Development  Loop 


Identify  Functionality  and  Quality  Attributes  -  The  first  step  in  the  SDL 
transforms  the  initial  service  description,  assumptions,  and  context  about  the 
system  state  into  a  detailed  functionality  list  (actions  and  outputs)  and  relevant 
quality  attributes.  These  items  heavily  influence  the  service’s  design. 
Stakeholders  prioritize  the  functionality  and  quality  attributes  in  the  SDL’s  next 
steps.  This  process  ensures  the  appropriate  scope  of  work  for  the  current  loop 
iteration.  The  first  iteration  creates  a  fairly  simple  service,  focusing  on  the  most 
important  quality  attributes.  Future  iterations  deliver  increased  complexity  until 
they  meet  all  service  requirements. 

Develop  Quality  Attributes  and  Functionality  Scenarios  -  This  step  creates 
brief,  precise  scenarios  that  make  the  functionality  and  quality  attributes 
concrete.  These  scenarios  ensure  the  development  team  and  stakeholders 
accurately  understand  what  the  new  service  does  and  how. 

Prioritize  and  Select  -  The  scenarios  generated  during  the  previous  step 
and  “voice  of  the  customer”  prioritize  the  functionality  and  quality  attributes.  The 
stakeholders  and  development  team  choose  the  scenarios  to  implement  during 
the  current  SDL  iteration.  Because  the  scenarios  directly  correspond  to 
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functionality  and  quality  attributes,  everyone  involved  understands  the  service’s 
requirements. 

Identify  External  Interactions  and  Interfaces  -  The  next  step  identifies  the 
external  services,  systems,  and  data  the  service  consumes  to  produce  the 
desired  output.  Additionally,  it  specifies  the  incoming  message  type,  content, 
and  format,  which  define  the  service  invocation  methods.  Similar  details 
describe  the  service’s  output.  These  definitions  specify  the  service’s  interfaces. 

Select  Measures  -  This  step  supports  continuous  improvement  by 
identifying  what  aspects  to  measure  to  determine  if  the  service  provides  the 
required  functionality  and  quality  attributes.  Each  measurement  includes 
thresholds  that  clearly  define  success  or  failure. 

Develop  and  Deploy  Service  -  The  previous  five  steps  create  a  logical  and 
understandable  service  definition.  This  step  develops  and  deploys  that  service  to 
provide  the  prioritized  functionality  and  quality  attributes,  using  the  proper 
interfaces.  Following  deployment,  we  return  to  the  Architecture  Loop  to  continue 
that  process.  The  SDL  also  continues  with  two  more  steps  in  the  loop. 

Measure  and  Evaluate  -  This  step  collects  the  measurements  and 
evaluates  them  based  on  stated  thresholds.  This  determines  whether  or  not  the 
service  works  as  expected  and  meets  the  users’  needs.  Stakeholder  feedback 
identifies  new  requirements  for  future  development  and  revision.  The  SDL 
restarts  at  the  “Identify”  step  to  address  existing  defects  or  develop  new 
requirements. 

Review  and  Adjust  Process  -  Continuous  improvement  also  extends  to 
the  process  used  to  develop  the  service.  The  development  process  trials  and 
tribulations  will  result  in  “lessons  learned,”  used  to  improve  the  SDL  during  future 
loops. 

4.  IDeA  Conclusion 

We  believe  our  proposed  two-loop  method  provides  the  Coast  Guard  with 
a  flexible  and  incremental,  design  and  implementation  process.  The  IDeA 
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method  will  immediately  deliver  useful  services,  and  provide  evolutionary 
architectural  improvement.  Each  loop  cycle  will  not  only  develop  additional 
services  but  also  allows  us  to  improve  our  developmental  methodology  as  we 
learn  more  about  our  needs  and  the  technology. 

C.  ORGANIZE  FOR  SUCCESS 

Designing  and  implementing  a  SOA  should  revolutionize  the  Coast 
Guard’s  information  technology  capabilities  and  infrastructure.  The 
organizational  impact  can  and  should  be  equally  as  dramatic.  Consider  the 
transformation  at  Amazon.com  in  2001.  The  online  retail  giant  realized  their 
existing  monolithic  application  could  not  scale  to  meet  future  needs.  Amazon 
implemented  an  SOA  and  organized  their  numerous  development  teams  around 
the  services  within  the  SOA.  Amazon’s  Chief  Technical  Officer  (CTO)  Werner 
Vogels  describes  the  impact  this  approach  had  in  the  following  quote: 

The  services  model  has  been  a  key  enabler  in  creating  teams  that 
can  innovate  quickly  with  a  strong  customer  focus.  Each  service 
has  a  team  associated  with  it,  and  that  team  is  completely 
responsible  for  the  service — from  scoping  out  the  functionality,  to 
architecting  it,  to  building  it,  and  operating  it.  ...  There  is  another 
lesson  here:  Giving  developers  operational  responsibilities  has 
greatly  enhanced  the  quality  of  the  services,  both  from  a  customer 
and  a  technology  point  of  view.  The  traditional  model  is  that  you 
take  your  software  to  the  wall  that  separates  development  and 
operations,  and  throw  it  over  and  then  forget  about  it.  Not  at 
Amazon.  You  build  it,  you  run  it.  This  brings  developers  into  contact 
with  the  day-to-day  operation  of  their  software.  It  also  brings  them 
into  day-to-day  contact  with  the  customer.  This  customer  feedback 
loop  is  essential  for  improving  the  quality  of  the  service.  (Gray) 

The  Coast  Guard  operates  in  the  traditional  model  described  by  Vogels. 
One  group  envisions  each  system,  another  designs  it,  and  a  third  foists  it  on  the 
user.  Our  traditional  approach  created  our  existing  stovepipe  applications  that 
don’t  meet  our  current  or  future  needs.  We  need  to  seize  the  opportunity  that 
SOA  provides  and  break  this  pattern  by  changing  our  system  development 
organization  to  replicate  Amazon’s  approach. 
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The  first  step  in  our  organizational  makeover  designates  the  chief 
architect.  This  person  must  have  a  credible  architectural  vision  and  the  ability  to 
communicate  it  to  others  in  a  clear  and  convincing  way.  He  or  she  will  lead  the 
architecture  design  team  to  produce  the  overall  SOA2,  including  guidance  other 
development  teams  will  follow.  In  addition,  this  team  will  act  as  the  steering 
committee.  The  team  will  proactively  manage  the  service  development, 
deployment,  and  improvement  efforts  that  occur  during  the  IDeA  method 
iterations.  They  will  also  identify  the  resources  required  to  implement  and 
maintain  the  CGC2  SOA.  These  resources  include  hardware,  software, 
personnel,  training,  and  other  funding  items. 

Continuing  to  emulate  Amazon’s  approach,  we  will  have  each  existing 
organizational  entity  develop  services  within  its  own  domain.  These  entities  will 
form  development  teams  that  create,  deploy,  maintain  and  evolve  services  using 
the  standards  and  guidance  from  the  chief  architect.  For  example,  the  Coast 
Guard  Operations  Systems  Center  (OSC)  owns  our  databases  and  therefore 
should  produce  the  data  and  enterprise  business  services.  The 
Telecommunications  and  Information  Systems  Command  (TISCOM)  should 
produce  network  and  security  services  and  propose  overall  system  policy 
standards.  The  Coast  Guard  Command  and  Control  Engineer  Center  (C2CEN) 
should  produce  the  operational  tasking,  geospatial  display,  and  sensor 
monitoring  services.  These  three  commands  would  also  collaborate  to  share 
lessons  learned  and  propose  modifications  to  the  standards  and  polices  that  the 
chief  architect  establishes. 

D.  BEST  PRACTICES  AND  WORST  PRACTICES 

This  section  continues  our  “learning  from  others”  approach  to  implement 
the  CGC2  SOA  successfully.  While  researching  and  writing  this  thesis,  we 
noticed  several  recurring  suggestions  that  we  should  pay  careful  attention  to, 
understand  and  use.  The  diagram  below  contains  those  fundamental  “best 


2  We  think  the  SOA  presented  in  Chapter  3  provides  an  excellent  starting  point. 
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practices”  and  “worst  practices”  that  various  companies  and  individuals  working 
in  the  SOA  marketplace  have  identified. 


Know  when  to 
use  services 


systems  at  once  industry  standards 


Figure  26.  SOA  Best  Practices  and  Worst  Practices 


Know  when  to  use  services  -  This  best  practice  requires  that  we  explicitly 
define  the  extent  to  which  we  will  use  services.  Using  a  Web  service  does  not 
require  an  entirely  new  application  architecture.  SOA’s  loosely  coupled  design 
allows  the  limited  addition  of  services  without  a  negative  impact  on  the  remaining 
application  architecture.  (Erl  448)  The  corollary  to  this  best  practice  advises  us 
to  “know  when  to  avoid  services.”  The  “Technical  Strategy”  and  “Design  SOA” 
Architecture  loop  steps,  introduced  earlier  in  this  chapter,  apply  these  two  best 
practices.  We  actively  select  what  to  create  in  each  service  development  cycle. 
Services  will  not  randomly  spring  up  across  the  Coast  Guard’s  enterprise 
architecture. 

Think  big  but  start  small  -  This  best  practice  appeared  in  almost 
everything  we  read.  “Be  selective.  Don’t  start  with  a  massive  project  that 
involves  a  cast  of  thousands.  Think  big  but  start  with  a  small  project.  Focus  on  a 
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project  that  can  highlight  the  clear  benefits  of  SOA  like  reworking  a  small  set  of 
key  business  processes  to  improve  their  flexibility.”  (Coticchia  8)  The  IDeA 
method  fully  supports  this  best  practice.  Starting  small  validates  the  architecture 
while  giving  the  organization  value,  realized  as  usable  services.  We  don’t  want 
to  develop  a  collection  of  fragmented  services.  To  avoid  this  we  need  to  “create 
the  architecture  and  deploy  specific  services  in  phases,  perhaps  focusing  on  one 
application  domain  at  a  time  or  choosing  projects  based  on  business  urgency.” 
(Gruman) 

Replace  all  legacy  systems  at  once  -  This  worst  practice  states  that 
migrating  the  entire  enterprise  to  SOA  in  one  large  project  "...  is  a  recipe  for 
disaster.  Theoretically,  it  may  seem  like  a  good  idea  to  jump  right  into  SOA 
implementation,  ripping  out  and  replacing  all  existing  systems  at  once.  SOA 
technology  is  new,  exciting  and  hugely  beneficial,  and  it’s  easy  to  get  carried 
away.”  (Foody  28,29)  The  Coast  Guard’s  SOA  implementation  plan  should 
migrate  our  entire  enterprise  to  SOA  over  many  years.  The  IDeA  method’s 
incremental,  evolutionary  approach  avoids  this  worst  practice. 

Build  on  what  you  have  -  This  best  practice  considers  "...  reusing  legacy 
logic  before  replacing  it.  Web  services  can  let  you  take  advantage  of  what  you 
already  have  through  the  use  of  adapters  and  service  layers.”  (Erl  451)  Each 
IDeA  method  iteration  should  reuse  legacy  application  functionality  and  data 
wherever  possible.  For  example,  the  AOPS  database  records  asset  employment 
data.  It’s  a  burden  for  the  all  the  organizational  levels  to  keep  current.  We  can 
transform  this  database  from  a  historical  archive  into  the  Coast  Guard’s  assets 
status  board. 

Use  SOA  to  streamline  business  processes  -  This  best  practice 

capitalizes  on  SOA’s  inherently  flexible  and  interoperable  model  for  hosting 

application  functionality.  SOAs  provide  an  opportunity  to  rethink  and  improve 

business  processes.  The  Coast  Guard  should  grasp  this  opportunities  to 

streamline  its  business  processes.  Continuing  the  AOPS  example,  the  database 

update  could  be  worked  into  every  business  process  that  tasks  assets  and 
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impacts  their  employment  category.  This  would  streamline  a  currently  disjointed 
work  flow. 

Incorporate  standards  -  This  best  practice  suggests  using  the  industry 
Web  service  standards  (W3C,  OASIS)  as  the  standards  for  the  Coast  Guard’s 
SOA.  “In  an  enterprise,  this  can  potentially  translate  into  a  standardized  system 
for  navigating:  application  logic,  integration  architectures,  corporate  data  stores, 
and  parts  of  the  enterprise  infrastructure.”  (Erl  454)  The  initial  Architecture  Loop 
iteration  should  identify  which  standards  will  be  used. 

Deviate  from  industry  standards  -  Modifying  those  industry  standards  to  fit 
within  current  system  configuration  creates  more  problems  than  it  solves.  This 
worst  practice  occurs  when  people  try  to  save  time  and  money  during  the  current 
development  cycle.  However,  standards  exist  for  a  reason;  modifying  them  can 
cause  unintended,  severe  interoperability  issues.  Customizing  standards 
requires  special  code  at  every  affected  service  or  node  to  function  properly.  This 
creates  brittle  connections  and  defeats  the  purpose  of  a  loosely-coupled  SOA. 
The  Coast  Guard  should  avoid  this  problem. 

Build  around  a  security  model  -  “The  functional  design  needs  to  be  built 
upon  the  security  model,  not  the  other  way  around.  Putting  together  a  design, 
and  perhaps  even  building  a  preliminary  version  of  your  [system]  without  serious 
consideration  for  the  underlying  security  model  is  a  common  mistake.”  (Erl  463) 
This  best  practice  recognizes  that  security  often  cannot  be  added  to  an 
architecture  or  application  as  an  afterthought.  The  CGC2  SOA  requires  strong 
security.  Therefore  the  Coast  Guard  must  include  it  in  the  initial  architecture 
design. 

Design  with  quality  in  mind  -  “This  has  never  been  more  important  than  in 
an  SOA  environment.  Specifically  for  a  development  issue,  quality  must  be 
designed  into  the  product  not  inspected  into  it.”  (Coticchia  9)  The  Coast  Guard 
must  identify  key  quality  attributes  and  then  properly  balance  their  trade-offs 
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when  designing  the  SOA.  The  utility  tree  in  Chapter  3  provides  a  good  starting 
point  for  the  Coast  Guard. 

Organize  development  resources  -  This  best  practice  groups 
development  teams  around  logical  business  tasks.  “A  common  mistaken  during 
development  projects  is  to  have  one  team  deliver  the  Web  services  and  a 
different  team  develops  the  rest  of  the  application.  This  approach  may  make 
sense,  because  you  have  each  team  working  with  technologies  that  they  know 
how  to  use.  It  can  make  the  resulting  application  seem  disjointed  and  non- 
intuitive  to  the  user.”  (Erl  465)  Section  C  above  embodies  this  best  practice. 

Train  developers  -  This  best  practice  ensures  that  designers  and 
developers  have  the  skills  necessary  to  implement  the  Web  services  properly. 
(Erl  466)  Software  developers  need  to  understand  service-oriented  principles  and 
practices,  as  well  as  the  Web  services  technical  details.  The  Coast  Guard 
should  identify  and  provide  the  training  each  development  team  member 
requires.  While  this  costs  money,  it  pays  big  dividends. 

E.  SOA’S  IMPACT  ON  QUALITY  ATTRIBUTES 

While  creating  the  architecture  description  in  Chapter  III,  we  compiled  a 
list  of  possible  quality  attributes.  We  ranked  them  based  on  our  personal 
judgment  about  their  importance  to  a  Coast  Guard  command  and  control  system 
architecture.  Figure  27  below  shows  this  ranking.  We  selected  the  top  five 
quality  attributes  and  used  them  to  develop  the  utility  tree  in  Chapter  III  (Figure 
8).  The  other  seven  quality  attributes  certainly  require  some  attention  when 
developing  a  system  based  on  this  architecture.  However,  we  feel  that  the  top 
five  would  most  influence  the  architectural  design  and  should  receive  greater 
attention. 
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Figure  27.  Quality  Attribute  Importance  for  CGC2  SOA 


A  September  2005  report  from  the  Software  Engineering  Institute  (SEI) 
addresses  the  positive  and  negative  effects  that  an  SOA  has  on  a  system’s 
quality  attributes.  We  assessed  the  material  in  that  report  and  then  ranked  our 
top  five  quality  attributes  based  on  SOA’s  maturity  level.  Figure  28  shows  the 
quality  attributes  well  supported  by  SOA  in  green.  The  color  red  indicates  quality 
attributes  not  well  supported  by  current  SOA  technologies.  We  discuss  the 
impact  of  these  support  concerns  in  the  following  paragraphs. 


Interoperability 


Scalability 


Security 


Extensibility 


Usability 


Figure  28.  SOA  Support  for  Quality  Attributes 
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We  have  taken  the  quality  attributes  from  Figure  28  above  and  quoted  the 
appropriate  sections  from  the  SEI  report  in  Table  5.  The  “status”  column  refers 
to  SOA’s  maturity  level  for  the  quality  attribute.  “The  color  green  indicates  that 
there  are  known  solutions  for  the  SOA  based  on  relatively  mature  standards  and 
technology.  The  color  yellow  indicates  that  some  solutions  exist  but  need  further 
research  to  prove  their  usefulness  in  handling  the  requirements  for  the  quality 
attribute.  The  color  red  indicates  that  the  standards  and  technology  are 
immature  and  further  significant  effort  is  required  to  fully  support  the  quality 
attribute  within  an  SOA.”  (O’Brien,  Bass,  and  Merson  22) 


Quality  Attribute 

Status 

Summary 

Interoperability 

Green 

“Through  the  use  of  the  underlying  standards,  an  SOA 
provides  good  interoperability  technology-wise  overall, 
allowing  services  and  applications  built  in  different  languages 
and  deployed  on  different  platforms  to  interact.  However, 
semantic  interoperability  is  not  fully  addressed.  The  standards 
to  support  semantic  interoperability  are  immature  and  still 
being  developed.” 

Security 

Red 

“The  need  for  encryption,  authentication,  and  trust  within  an 
SOA  approach  requires  detailed  attention  within  the 
architecture.  Many  standards  are  being  developed  to  support 
security,  but  most  are  still  immature.  If  these  issues  are  not 
dealt  with  appropriately  within  the  SOA,  security  could  be 
negatively  impacted.” 

Usability 

Yellow 

“Usability  may  decrease  if  the  services  within  the  application 
support  human  interactions  with  the  system  and  there  are 
performance  problems  with  the  services.  It  is  up  to  the 
services  users  and  providers  to  build  support  for  usability  into 
their  systems.” 

Extensibility 

Green 

“Extending  an  SOA  by  adding  new  services  or  incorporating 
additional  capabilities  into  existing  services  is  supported  within 
an  SOA.  However,  the  interface/formal  contract  must  be 
designed  carefully  to  make  sure  that  it  can  be  extended,  if 
necessary,  without  causing  a  major  impact  on  the  service 
users.” 

Scalability 

Yellow 

“There  are  ways  to  deal  with  an  increase  in  the  number  of 
service  users  and  the  increased  need  to  support  more 
requests  for  services.  However,  these  solutions  require 
detailed  analysis  by  the  services  providers  to  make  sure  that 
other  quality  attributes  are  not  negatively  impacted.” 

Table  5.  SOA  Quality  Attribute  Impact  (After:  O’Brien,  Bass,  and  Merson  Table  1 ) 
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The  Coast  Guard’s  architects  and  implementers  need  to  understand 
SOA’s  strengths  and  weakness  when  designing  and  building  the  CGC2  SOA. 
Our  success  depends  on  our  ability  to  properly  identify  and  address  the 
limitations  of  the  technology  that  support  the  architectural  approach.  The 
following  paragraphs  provide  our  specific  responses  for  each  quality  attribute. 
However,  we  should  closely  monitor  the  emergence  and  improvement  of  industry 
standards  and  best  practices  for  every  quality  attribute.  Each  successive  IDeA 
loop  cycle  should  selectively  implement  the  standards  and  best  practices 
appropriate  to  our  needs. 

Interoperability  -  SOA  strongly  supports  this  quality  attribute.  The  SEI’s 
concern  about  semantic  interoperability  can  partially  be  addressed  with 
appropriate  information  exchange  data  models. 

Security  -  Several  web  service  standards  support  confidentiality, 
authenticity,  integrity,  and  non-repudiation.  These  standards  have  been  updated 
with  more  mature  versions  since  the  SEI  report  appeared.  Therefore  we 
disagree  with  the  “red”  status  and  would  classify  it  currently  as  yellow.  This 
comment  does  not  diminish  the  security  problem’s  complexity.  We  will  likely 
develop  multiple  approaches  to  meet  the  needs  of  users  that  have  established 
various  trust  relationships.  This  quality  attribute  obviously  must  be  approached 
architecturally,  incrementally,  and  without  excessive  risk,  delay,  or  simplifications 
that  produce  either  an  overly  rigid  system  or  an  insecure  one.  Additionally, 
providing  the  Public  Key  Infrastructure  (PKI)  required  to  implement  these 
standards  will  require  careful  consideration  early  in  the  IDeA  process. 

Extensibility  -  SOA  also  strongly  supports  this  quality  attribute.  The  IDeA 
method  will  enforce  properly  designed  interfaces,  enabling  each  service  to  be 
extended  without  negatively  impacting  users. 

The  decisions  made  by  the  architects  and  developers  heavily  influence  the 
two  remaining  quality  attributes.  Implementing  a  certain  industry  standard  will 
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not  provide  required  usability  or  scalability.  However,  the  Amazon  approach 
(develop  services  with  the  same  people  that  provide  the  business  functionality) 
will  provide  the  proper  developer  motivation  and  perspective  to  deliver  these 
quality  attributes. 

Usability  -  Developers  address  undocumented  or  vaguely  defined 
performance  dimensions  when  they  understand  the  unique  user  requirements  for 
each  service.  This  inherent  awareness  of  user  needs  goes  a  long  way  to 
addressing  usability. 

Scalability  -  Amazon,  AT&T  and  British  Telecom  all  have  extremely  large- 
scale  SOAs.  It’s  very  important  to  properly  identify  and  address  scalability 
requirements  early  in  the  IDeA  process.  However  the  Coast  Guard’s  scalability 
concerns  won’t  exceed  those  of  industry-leading  SOA  adopters. 

F.  CONCLUSION 

Our  answer  to  the  second  thesis  question  proposed  an  iterative  method  to 
design  and  implement  the  architecture,  logically  organize  the  development 
teams,  and  learn  from  industry  best  practices.  Taken  as  a  whole,  this  collection 
provides  the  Coast  Guard  with  a  solid  foundation  to  begin  designing  and 
implementing  the  CGC2  SOA. 


89 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


90 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSION 

The  Coast  Guard  Commandant  recently  mandated  that  we  shift  our  IT 
infrastructure  to  an  SOA.  To  achieve  this,  we  must  carefully  determine  what  our 
SOA  will  look  like  and  how  we  will  successfully  build  it.  This  thesis  provides  the 
foundation  for  both.  In  Chapter  two,  we  began  by  defining  SOA  concepts  and 
technologies.  Many  SOA  technical  standards  and  enabling  software  remain 
immature,  but  the  industry  improves  them  at  a  quick  and  steady  pace.  We  must 
monitor  their  continued  advances  and  adjust  our  SOA  accordingly.  In  Chapter 
three  we  described  how  the  Coast  Guard  could  implement  a  command  and 
control  SOA.  We  included  the  services,  their  interactions,  the  data,  and  the 
quality  attributes  the  architecture  must  address.  Chapters  two  and  three  thus 
crystallize  what  the  Commandant  has  mandated. 

SOA  forces  us  to  change  the  way  we  conceive  and  implement  our 
information  technology,  shifting  from  vertical  stove-piped  systems  to  horizontally 
integrated  ones.  In  Chapter  four,  we  introduced  a  two-loop  method  for 
incrementally  building  the  SOA  in  a  way  that  evolves  from  the  present  towards 
the  constantly  moving,  desired  future  state.  Focusing  on  short,  clearly  defined 
implementation  cycles  allows  us  to  incorporate  lessons  learned  to  improve  the 
architecture,  its  components,  and  the  way  we  create  them.  We  reviewed  several 
industry  best  practices  and  common  pitfalls,  including  a  recommended 
organizational  alignment  deemed  crucial  to  Amazon’s  successful  SOA.  Finally, 
we  discussed  the  impact  an  SOA  has  on  our  chosen  quality  attributes.  Chapter 
four  thus  answers  how  we  should  meet  the  Commandant’s  mandate. 

We  began  our  thesis  research  by  reading  several  white  papers,  from 
companies  selling  SOA  software  products  or  consulting  services  to  implement 
SOAs.  These  papers  described  SOA  solving  every  computer  system  integration 
and  data  sharing  problem  in  existence.  Our  further  research  and  practical 
experience  with  the  Comprehensive  Maritime  Awareness  JCTD  proved 
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otherwise.  Contrary  to  the  advertisements,  we  cannot  simply  purchase  an  SOA 
from  a  vendor  or  order  the  Coast  Guard’s  IT  staff  to  create  one.  The  Coast 
Guard’s  requirements  to  reach  mobile  platforms  further  complicate  matters.  We 
can  not  rely  on  ample  internet  bandwidth  to  extend  the  SOA  to  boats,  aircraft, 
and  cutters.  After  finishing  our  research  and  thesis  work,  we  conclude  that  SOA 
does  not  provide  “the  answer  to  everything.”  Nevertheless,  we  believe  that  SOA, 
properly  managed,  can  deliver  tremendous  benefit  to  the  Coast  Guard.  We  think 
that  Coast  Guard  can  and  should  use  SOA  to  revolutionize  our  command  and 
control. 

B.  RECOMMENDED  FUTURE  RESEARCH 

While  researching  and  writing  this  thesis  we  identified  several  items  that 
future  NPS  thesis  students  can  develop  further.  We  list  them  below. 

1.  Coast  Guard  Data  Models 

In  this  thesis  we  created  basic  data  models  for  demonstration  purposes 
only.  A  graduate  student  could  devote  his  or  her  thesis  to  researching  and 
developing  the  data  model  for  the  entire  CGC2  SOA  or  merely  develop  the  most 
valuable  data  models  for  near-term  implementation.  Either  way,  this  difficult  but 
crucial  effort  would  require  close  work  with  several  Coast  Guard  entities. 

2.  Planning  Services  Based  on  MHS-OPS 

The  MHS-OPS  developers  implemented  a  useful  HLS  planning  and 
tasking  tool  for  homeland  security.  Unfortunately,  they  built  another  stovepipe 
system.  We  recommend  a  thesis  student  service-enable  the  MHS-OPS 
functionality,  at  the  proper  level  of  abstraction,  so  all  Coast  Guard  mission  areas 
can  use  it. 

3.  Operations  Watchstander  Console 

The  typical  Coast  Guard  command  center  watchstander  has  to  manage 
multiple  computer  screens  connected  to  many  different  computer  systems.  We 
envision  a  single  integrated  composite  application  to  manage  all  watchstander 
computing  and  information  management  tasks.  It  should  manage  operational 
tasking,  checklists  and  watch  logs  and  ensure  the  watchstander  complies  with 
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Coast  Guard  regulations  and  local  SOPs.  A  graduate  student  could  research 
and  develop  all  or  part  of  the  composite  application. 

4.  PKI  for  SOA 

The  Coast  Guard  must  address  service  and  security  early  in  its  SOA 
development.  We  need  appropriate  PKI  to  issue  credentials  to  users  and 
services  (including  end  systems)  operating  in  the  SOA.  The  solution  to  this  non¬ 
trivial  problem  will  address  an  important  quality  attribute  and  will  be  reused  in  all 
Coast  Guard  SOAs.  A  graduate  student  could  research  the  security  and  PKI 
aspects  of  current  DoD  SOA  implementations  and  propose  a  Coast  Guard 
specific  solution.  Regardless  of  graduate  research,  the  Coast  Guard  needs  to 
make  this  an  action  item  for  development  funding  and  implementation. 

5.  XMPP  for  Coast  Guard  Command  and  Control 

The  United  States  Marine  Corps  recently  adopted  XMPP  as  its  standard 
instant  messaging  protocol.  XMPP  can  provide  much  more  than  chat  and  instant 
messaging  within  an  SOA.  NPS  faculty  and  students  have  researched  using 
XMPP  for  passing  data  (e.g.,  tracks)  between  battlespace  nodes.  We 
recommend  researching  XMPP  as  a  means  to  pass  operational  tasks  (e.g., 
search  patterns)  between  Coast  Guard  units.  The  data  needs  to  have  proper 
formatting  for  easy  transfer  into  cutter,  boat,  and  aircraft  navigation  systems. 
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APPENDIX  A.  U.S.  COAST  GUARD  ORGANIZATIONAL 

RELATIONSHIPS 


A.  WITHIN  THE  FEDERAL  GOVERNMENT 

As  a  component  within  the  Department  of  Homeland  Security,  the  Coast 
Guard  “protects  the  public,  the  environment,  and  U.S.  economic  interests — in  the 
nation’s  ports  and  waterways,  along  the  coast,  on  international  waters,  or  in  any 
maritime  region  as  required  to  support  national  security.”  (“Department 
Subcomponents  and  Agencies”) 

B.  WITHIN  THE  COAST  GUARD 

The  Coast  Guard  has  divided  its  operational  commands  into  geographic 
zones,  with  the  Atlantic  Area  and  Pacific  Area  commanders  reporting  to  the 
Commandant.  Figure  29  shows  the  Coast  Guard’s  top  level  operational 
command  structure. 


Figure  29.  Coast  Guard  Operational  Chain  of  Command 
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Both  Areas  are  divided  into  Districts  that  cover  several  hundred  miles  of 
coastline.  They  generally  correspond  to  a  geographic  region,  for  example  the 
First  Coast  Guard  District  encompasses  New  England,  stretching  from  Maine 
through  New  Jersey. 

Each  District  is  sub-divided  into  Sectors,  shown  in  the  Figure  30.  Each 
Sector  has  several  operational  units  under  its  command. 


Figure  30.  U.S.  Coast  Guard  Sector  Commands  (From:  Command  Center 

Program  Manual  Figure  2-1-1 ) 


C.  WITHIN  THE  SECTOR 

Each  Sector  command  center  (CC)  performs  the  duties  shown  in  Figure 
31  and  described  below: 
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Figure  31 .  Sector  Command  Center  Duties  (After:  Command  Center  Program 

Manual  Figure  2-2-2) 

CDO:  “The  CDO  is  responsible  for  the  performance  of  the  watch  in  the 
execution  of  its  primary  functions  and  ensuring  proper  coordination  of  operational 
plans  for  a  specific  operational  period.” 

Situation  Unit:  “The  Situation  Unit  is  primarily  responsible  for  monitoring 
the  AOR,  tracking  the  activities  and  readiness  of  blue  forces,  collecting  and 
fusing  of  important  information,  and  developing  the  local  tactical  picture.” 

Operations  Unit:  “The  Operations  Unit  is  responsible  for  the  planning  and 
execution  of  incident  response  missions  conducted  within  the  AOR.  At  the 
different  levels  of  CCs,  these  responsibilities  may  translate  into  different 
positions.  For  example,  some  District  and  Sector  CCs  may  have  a  staffed  Law 
Enforcement  watch  position  because  of  the  elevated  operational  tempo 
(OPTEMPO)  in  LE  cases  within  the  AOR.  Others  rely  on  an  on-call  Law 
Enforcement  Duty  Officers  (LEDOs)  for  SME  guidance  during  LE  cases. 
Additionally,  District  and  Area  CCs  may  elect  to  assign  an  officer  with  LEDET, 
MSST,  or  MSRT  experience  to  plan  and  monitor  use  of  Special  Missions  assets.” 

Comms  Unit:  “The  Comms  Unit  is  responsible  for  monitoring  required 
voice  frequencies,  maintaining  communication  guard  requirements,  and,  as 
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directed,  executing  tactical  communication  for  response  operations.”  ( Command 
Center  Program  Manual  55-56) 

D.  CONCLUSION 

The  Coast  Guard  Commandant  recently  announced  changes  to  our 
command  structure.  The  information  in  this  appendix,  particularly  at  the  District 
and  Area  level  will  change  in  the  near  future.  However,  we  feel  that  this 
appendix  allows  non-Coast  Guard  readers  to  understand  our  current 
organizational  layout  as  it  is  discussed  throughout  the  thesis. 
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APPENDIX  B.  COMMUNICATIONS  INTEROPERABILITY 


A.  NETWORK-CENTRIC 

The  Coast  Guard  cannot  implement  Network  Centric  Operations  (NCO) 
without  a  network,  or  more  specifically  a  network  with  the  right  capabilities  that 
connects  the  right  people  and  things.  It  is  extremely  unlikely  that  a  single 
program  or  platform  can  bring  about  a  transformation  of  the  Coast  Guard’s  IT 
infrastructure  to  close  the  gap  between  what  we  have  and  what  we  need. 
Therefore,  it  is  imperative  that  we,  as  an  organization,  share  a  common  view  of 
these  requirements  and  ensure  that  all  current  and  future  acquisitions  work 
toward  a  common  goal.  In  short,  we  need  a  consistent  procurement  approach 
that  delivers  components  that  meet  these  requirements. 

Current  command  and  control  methodology  places  the  various  sense, 
decide,  and  act  systems  at  the  center  of  the  diagram.  Network  Centric 
Operations  places  the  network  at  the  center  as  the  key  enabling  technology. 
This  perspective  views  all  attached  devices,  services,  and  systems  as  nodes  on 
the  network.  To  enable  NCO,  the  network  definition  includes:  internet  protocol 
(IP)  routing,  support  for  public  key  infrastructure  (PKI),  and  message  prioritization 
options  for  quality  of  service  (QoS)  beyond  “best  effort”  delivery.  It  also  means 
that  all  nodes  and  devices  have  three  types  of  interfaces:  network  interfaces, 
management  interfaces,  and  messaging  interfaces. 

While  the  Coast  Guard  has  generally  done  well  acquiring  network 
infrastructure  with  the  internet  protocol  (IP)  data  network  reaching  most  users. 
However,  the  fatal  exception  occurs  at  the  “last  mile.”  The  IP  network  has  not 
been  extended  out  to  small  boats,  patrol  boats,  and  aircraft.  Further,  many  of  the 
operational  end  systems  such  as  radars  on  large  cutters  have  not  been  attached 
to  the  unit's  LAN.  The  Coast  Guard’s  lag  to  extend  network  reach  to  mobile 
assets  stems  from  the  complexity  of  the  problem  itself.  The  combination  of  the 
operating  environment,  distance,  mobility,  RF  spectrum,  and  availability  of 
inexpensive  hardware/software  products  all  conspire  to  make  this  difficult.  There 
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are  some  initial  solutions  out  in  the  marketplace  but  many  have  not  reached  the 
level  of  maturity  to  allow  the  Coast  Guard  to  implement  them  on  a  large  scale. 
The  Naval  Postgraduate  School  (NPS)  has  done  research  and  experiments 
using  products  conforming  to  IEEE  802.16  standard,  but  the  experimentation  has 
not  shown  that  it  meets  all  Coast  Guard  requirements.  However,  802.16  is  a 
rapidly  emerging  technology  that  may  provide  a  viable  solution  to  the  “last  mile” 
problem.  Regardless  of  the  how  it  gets  done,  the  Coast  Guard  needs  to  send 
and  receive  data  from  its  boats,  cutters,  and  aircraft. 

B.  REQUIRED  NETWORK  CAPABILITIES 

Before  diving  into  network  requirements  it  is  prudent  to  define  what  a 
network  is.  The  network  is  all  of  the  plumbing  that  connects  the  end  systems 
together.  The  plumbing  consists  of  the  switches,  routers  and  all  of  the  connecting 
wiring. 

These  requirements  apply  to  the  network  on  two  levels,  the  local  area 
network  (LAN)  within  one  unit  (boat,  cutter,  aircraft,  boarding  team,  etc.)  and  then 
the  wide  area  network  (WAN)  connecting  all  units.  The  LAN  connects  all  “sense, 
decide,  act”  systems  within  a  unit,  examples  include:  GPS,  radar,  radios,  and 
cameras.  A  router  connects  the  single  unit  to  all  other  units  via  the  WAN.  In 
addition  to  the  necessary  bandwidth  to  transmit  the  messages  required  by  the 
SOA,  both  the  LAN  and  WAN  must  have  the  following: 

1.  Availability 

Availability  is  critical  to  effective  network  communications.  When  we  say 
availability  we  mean  that  you  must  not  have  a  single  point  of  failure.  Redundant 
data  paths  may  not  be  feasible  in  every  situation  but  it  is  important  along  crucial 
communication  routes.  Capacity  is  another  important  and  often  overlooked 
aspect  of  availability.  A  working  link  that  cannot  handle  the  bandwidth 
requirements  is  the  same  as  no  link  at  all  for  most  users. 

2.  Quality  of  Service  (QoS) 

Quality  of  Service  control  mechanisms  provide  different  priority  to  different 
users  or  data  flows.  QoS  guarantees  become  more  important  when  the  network 
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capacity  is  limited,  like  the  Coast  Guard’s  “last  mile”  reach  to  mobile  assets.  This 
vital  concept  has  not  been  addressed  with  the  CGDN,  which  relies  on  traditional 
“best  effort”  that  performance  is  dependent  on  the  current  network  traffic  load. 
However,  as  services  are  added  and  users  rely  on  data  feeds  for  mission  critical 
situations,  prioritization  of  packets  will  become  necessary.  For  example 
messages  that  contain  the  details  of  a  search  pattern  must  be  received  quickly 
and  in  tact.  Effectively  balancing  network  load  will  be  critical  for  low-bandwidth 
users  (small  boats  and  aircraft)  who  will  rely  on  QoS. 

3.  Public  Key  Infrastructure  (PKI) 

Traditionally  the  Coast  Guard  has  relied  on  transport  security,  or 
encrypting  the  data  pipes,  for  information  security. 

However,  in  a  SOA  the  messages  themselves  require  more  robust 
security  capabilities,  especially  when  interacting  with  data  sources  outside  the 
Coast  Guard  network.  The  Coast  Guard  must  also  interact  with  agencies  outside 
the  Federal  Government  and  the  Military.  This  adds  a  level  of  complexity  to  the 
security  equation. 

Public  Key  Infrastructure  provides  the  foundation  for  multiple  security 
qualities  including: 

•  Authenticity  -  the  sender’s  identification  is  correct 

•  Confidentiality  -  authorized  users  are  granted  access  to  information 
and  unauthorized  users  are  denied  access. 

•  Integrity  -  the  information  has  not  been  tampered  with  during  the 
transit  between  sender  and  receiver. 

•  Non-repudiation  -  the  sender  can  not  refute  sending  the  message 
and  the  receiver  can  not  refute  delivery. 

With  PKI  in  place,  the  services  that  make  up  the  SOA  can  request  and 
provide  the  required  security  qualities.  PKI  provides  encryption  at  the  source  so 
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that  unprotected  data  never  touches  the  network  and  it  stays  protected  until  it 
reaches  the  destination. 

4.  SNMP  for  Remote  Management 

If  the  network  is  the  enabling  technology  at  the  center  of  our  operations, 
then  we  need  to  properly  monitor  and  manage  its  performance.  Network 
management  systems  (NMS)  use  the  Simple  Network  Management  Protocol 
(SNMP)  to  monitor  network-attached  devices  for  conditions  that  warrant 
administrative  attention.  SNMP  uses  software  agents  that  reside  on  the  network 
devices  to  translate  local  management  information  into  common  format. 

SNMP  agents  need  to  be  provisioned  onto  all  the  components  of  the 
information  systems  by  default.  The  NMS  monitors  the  network  and  generates 
alarms  when  conditions  are  not  within  defined  parameters.  This  is  extremely 
important  for  mobile  users  with  fragile  connections. 

C.  WEB  SERVICES  STACK 

The  final  requirement  is  a  method  for  distributing  the  data.  This  thesis 
describes  a  services  oriented  architecture  (SOA)  for  command  and  control  where 
the  data  is  exchanged  in  XML  formatted  messages  between  services.  The  World 
Wide  Web  Consortium’s  Web  Services  Architecture  Working  Group  defined 
technical  standards  to  ensure  interoperability  for  SOAs.  The  Working  Group 
divided  these  standards  into  the  following  six  areas:  processes,  descriptions, 
messages,  communications,  security  and  management:  Figure  32  shows  a 
modified  version  of  their  Web  Services  Architecture  Stack  diagram. 


110 


<D 

> 

C 

o 

O 

0) 

s§ 

w  g 
s.  w  5; 
^  >  0) 

IV  >* 

.9  w 
3  o  § 
O  cl  > 
LU  £vi 

t»5  2 

o  I- 
W  2? 


o 

a> 

CO 


co 


(0 

X 

d 

(0 

x 

_j 

s 

X 

co 

0) 

O) 

o 

o 

c 

J= 

o 

0) 

I- 

V 

in 

co 

CO 


PROCESSES 

UDDI,  WS-Coordination 


DESCRIPTIONS 

WSDL 


MESSAGES 

SOAP,  WS-ReliableMessaging,  WS-Addressing, 
WS-Notification,  WS-Eventing 


COMMUNICATIONS 

HTTP,  SMTP,  FTP 


co 

§ 

Z  w 
LU  m 

Ei 

0  la 

<3.  u 

o) 

<  £ 

^  03 


Figure  32.  Web  Services  Architecture  Stack  (After  “Web  Services  Architecture” 

Figure  3-1) 


1 .  Process  Layer 

The  Process  layer  describes  how  providers  publish  services  and 
requestors/consumers  discover  them. 

2.  Description  Layer 

The  Description  layer  describes  how  the  service  provider  communicates 
the  specifications  for  invoking  the  Web  service  to  the  service  requestor 

3.  Messages  Layer 

The  Messages  layer  describes  how  the  services  pass  information  in  the 
form  of  a  message 

4.  Communications  Layer 

The  Communications  layer  describes  how  messages  are  physically 
transported  across  the  network. 

5.  Security 

Security  occurs  at  all  layers  in  the  stack  and  it  provides  authenticity, 
integrity,  confidentiality,  and  non-repudiation. 
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6.  Management 

Management,  like  Security,  occurs  across  all  layers  in  the  stack. 
Management  provides  methods  for  monitoring  and  managing  services  and 
business  processes. 
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APPENDIX  C.  SEARCH  PATTERN  WEB  SERVICE 

SOURCE  CODE 


A.  CODE  OVERVIEW 

These  Java  classes  provide  the  search  pattern  Web  service.  The 
SearchPattern  class  is  the  actual  Web  service  code.  It  calls  methods  from  the 
Search  class.  The  methods  in  the  Search  class  are  ParallelSearch,  SectorSearch 
and  SquareSearch.  The  Search  class  calls  methods  from  the  Nav  class  to 
calculate  distance  and  bearing.  The  Position  class  is  the  instantiation  class  for 
the  position  object  that  is  the  core  component  of  all  searches.  The  WSDL 
provides  the  necessary  information  to  the  client  so  that  it  may  consume  the 
service.  It  defines  which  functions  may  be  called  and  the  parameters  that  are 
required  to  call  them. 

B.  SEARCH  PATTERN  CLASS 


/* 

*  SearchPattern . java 

* 

*  Created  on  November  20,  2006,  1:08  PM 

* 

*/ 

package  mil . uscg . nav; 

import  javax . jws . WebMethod; 
import  javax . jws .WebParam; 
import  javax . jws .WebService; 

/  *  * 

* 

*  @author  Bob  Creigh 
*/ 

@WebService ( ) 

public  class  SearchPattern  { 

/  *  * 

*  Web  service  operation 
*/ 

@WebMethod 

public  Object  parallelSearchWS ( @WebParam (name  =  "lat")  double  lat,  @WebParam (name  = 
"Ion")  double  Ion,  @WebParam (name  =  "length")  double  length,  @WebParam (name  =  "width") 
double  width,  @WebParam (name  =  "ma")  double  ma,  @WebParam (name  =  "ts")  double  ts)  { 
Search  search  =  new  Search (); 

String  posit  =  lat  +  "\t"  +  Ion  +  "\n"; 
int  i  =  0 ; 

search . ParallelSearch (lat.  Ion,  ma,  width,  length,  ts) ; 
for (i=0; i<search . size ( ) ; i++) { 
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\n")  ; 


posit  =  posit  +  (search. get (i) . getLat 0 )  +  "\t"  +  (search. get (i) .getLon  ()  + 


} 

return  posit; 


/  *  * 

*  Web  service  operation 
*/ 

@WebMethod 

public  Object  sectorSearchWS (@WebParam (name  =  "lat")  double  lat,  @WebParam (name  = 
"Ion")  double  Ion,  @WebParam (name  =  "theta")  double  theta,  @WebParam (name  =  "radius") 
double  radius,  @WebParam (name  =  "crs")  double  crs)  { 

Search  search  =  new  Search (); 

String  posit  =  lat  +  "\t"  +  Ion  +  "\n"; 
int  i  =  0; 

search. SectorSearch (lat,  ion,  theta,  radius,  crs); 
for (i=0; itsearch. size ( ) ; i++) { 

posit  =  posit  +  (sear ch.get (i) .getLat () )  +  "\t"  +  (search . get (i) . getLon () + 

"\n" )  ; 

} 

return  posit; 

} 

I  *  * 

*  Web  service  operation 
*/ 

@WebMethod 

public  Object  squareSearchWS (@WebParam (name  =  "lat")  double  lat,  @WebParam (name  = 
"Ion")  double  Ion,  @WebParam (name  =  "sqCount")  double  sqCount,  @WebParam (name  =  "ts") 
double  ts,  @WebParam (name  =  "crs")  double  crs)  { 

Search  search  =  new  Search (); 

String  posit  =  lat  +  "\t"  +  Ion  +  "\n"; 
int  i  =  0; 

search. ExpSquareSearch (lat,  ion,  sqCount,  crs,  ts); 
f or ( i=0 ; i<search ,size();i++){ 

posit  =  posit  +  (sear ch.get (i) .getLat () )  +  "\t"  +  (search . get (i) . getLon () + 

"\n" )  ; 

} 

return  posit; 

} 

} 

C.  SEARCH  CLASS 

/* 

*  Search. java 

* 

*  Created  on  September  8,  2006,  10:23  PM 

■ k 

*/ 

package  mil . uscg . nav; 
import  java.util.*; 

/  *  * 

* 

*  @author  Bob  Creigh 
*/ 

public  class  Search  { 

List<Position>  searchList  =  new  ArrayList<Position> ( )  ; 

/**  Creates  a  new  instance  of  Search  */ 
public  Search!)  { 

} 
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public  void  add(Position  pos)  { 
searchList . add (pos) ; 

} 


public  int  size(){ 

return  searchList . size  () ; 

} 

public  Position  get (int  i) { 
return  searchList . get ( i ) ; 

} 


public  void  ParallelSearch (double  lat,  double  Ion,  double  ma,  double  width,  double 
length,  double  ts) { 

/**  Generate  Parallel  Search  Pattern  Positions  from  parameters  **/ 
int  legs  =  (int) ( (length-ts) /ts) /2 ; 
double  legLength  =  width  -  ts; 
double  disti]  =  new  double  [4]; 
double  tk[]  =  new  double [4]; 
double  curLat  =  lat; 
double  curLon  =  Ion; 
int  posCount  =  0; 
int  i,  im¬ 
position  newPos  =  new  Position (); 

dist[0]  =  legLength; 
dist[l]  =  ts; 
dist[2]  =  legLength; 
dist[3]  =  ts; 

tk[0]  =  ma  -  90; 

if  (tk [ 0 ]  <  0 ) { tk [ 0 ]  =  tk [ 0 ]  +  360;}; 

tk[l]  =  ma; 

tk [2 ]  =  tk [ 0 ]  +  180; 

if  (tk [2 ]  >  360) {tk [3]  =  tk[3]  -  360;}; 
tk[3]  =  ma; 


for  (i  =  0;i  <  legs;  i++) { 
for ( j  =0 ; j  <4 ; j  ++)  { 

newPos  =  NavClass .posFromDistBrg (curLat,  curLon,  dist[j],  tk[j]); 
curLat  =  newPos . getLat () ; 
curLon  =  newPos . getLon ()  ; 
searchList . add (newPos)  ; 


newPos  =  NavClass .posFromDistBrg (curLat,  curLon,  dist[0],  t k [ 0 ] ) ; 
searchList . add (newPos) ; 


public  void  SectorSearch (double  lat,  double  Ion,  double  theta,  double  radius, 
crs )  { 


double  ell  =  (radius  /  60.0)  *  theta;  //  Cross  Leg  Length 


double  ncl  =  180.0  /  theta; 

double  nlegs  =  ncl  *  2; 

double  cca  =  (theta  /  2.0)  +  90.0; 

int  cllCount  =  0; 

double  tk  =  crs; 

double  dist[]  =  new  double [4 ]; 

Position  newPos  =  new  Position (); 

int  x  =  0; 


//  #  Number  of  Cross  Legs 
//  #  Number  of  Legs 
//  #  Course  Change  Angle 
//  #  Keep  track  of  cross  legs 


double 


double  curLat  =  lat; 
double  curLon  =  lon; 


dist [0] 
dist  [  1 ] 
dist  [2 ] 


radius; 
ell  ; 
radius; 
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while  (cllCount  <  ncl) { 

for  (x=0;  x  <  4;  x++) { 

newPos  =  NavClass .posFromDistBrg (curLat,  curLon,  dist[x],  tk)  ; 
curLat  =  newPos . getLat () ; 
curLon  =  newPos . getLon () ; 
searchList . add (newPos) ; 


if  (x  <  2)  { 

tk  +=  cca; 
if  (tk  >=  360) { 

tk  =  tk  -  360.0; 


cllCount  +=  1; 

} 

} 

public  void  ExpSquareSearch (double  lat,  double  Ion,  double  sqCount,  double  crs, 
double  ts) { 

/**  Generate  Parallel  Search  Pattern  Positions  from  parameters  **/ 
double  legLength  =  ts; 
double  tk  =  crs; 
double  curLat  =  lat; 
double  curLon  =  Ion; 

Position  newPos  =  new  Position (); 

int  i,  j; 


for  (i  =  0;i  <  sqCount;  i++) { 
for ( j  =0 ; j  <4 ; j  ++ )  { 

newPos  =  NavClass .posFromDistBrg (curLat,  curLon,  legLength,  tk)  ; 
curLat  =  newPos . getLat () ; 
curLon  =  newPos . getLon  () ; 
searchList . add (newPos) ; 


tk+=  90; 
if  (tk  >=  360) { 

tk  =  tk  -  360; 

} 


if  (j — 1)  f 

legLength+=  ts; 


if 


} 


} 


} 


( j  ==3 )  { 

legLength+=  ts; 


D.  NAV  CLASS 


/* 

*  NavClass . java 

* 

*  Created  on  September  1,  2006,  9:52  AM 

* 

*/ 
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package  mil . uscg . nav; 
import  java. util .ArrayList; 

/  *  * 

* 

*  @author  Bob  Creigh  creigh 
*/ 

public  class  NavClass  { 

/**  Creates  a  new  instance  of  NavClass  */ 
public  NavClass ()  { 

} 


public  static  Position  posFromDistBrg (double  aLat,  double  aLon,  double  aDist,  double 
aBrg )  { 

/**  Calculate  the  Lat  and  Lon  with  a  Distance  and  Bearing  **/ 

Position  newPos  =  new  Position  (0, 0) ; 
double  lat  =  Math. toRadians (aLat) ; 
double  Ion  =  0-Math. toRadians (aLon) ; 
double  dist  =  (Math. PI/ ( 180*60) ) *aDist; 
double  brg  =  Math. toRadians (aBrg) ; 

double  newLat; 
double  newLon ; 

newLat  = 

Math . toDegrees (Math . as in (Math . sin ( lat ) *Math .cos (dist) +Math .cos (lat) *Math . sin (dist ) *Math . c 
os  (brg)  )  )  ; 

newLon  =  0-Math . toDegrees ((( Ion  -  Math . asin (Math. sin (brg)  * 

Math . sin (dist ) /Math .cos (lat) ) +Math . PI )  %  (2  *Math . PI ) ) -Math . PI ) ; 

newPos . setLat (newLat) ; 
newPos . setLon (newLon) ; 

return  newPos; 

} 


} 

E.  POSITION  CLASS 


/* 

*  Position . j ava 

* 

*  Created  on  September  7,  2006,  10:17  AM 

* 

*/ 


package  mil . uscg . nav; 

/  *  * 

* 

*  @author  Bob  Creigh 
*/ 

public  class  Position  { 
private  double  Lat; 
private  double  Lon; 

/**  Creates  a  new  instance  of  Position  */ 
public  Position (double  aLat,  double  aLon)  { 
Lat  =  aLat; 

Lon  =  aLon; 


public  Position!)  { 

} 


public  void  setLat (double  aLat) { 
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Lat 


aLat; 


} 

public  void  setLon (double  aLon) { 
Lon  =  aLon; 

} 


public  double  getLat ( ) { 
return  Lat; 

} 


public  double  getLon ( ) { 
return  Lon; 

} 


public  static  String  LatToDegMin (double  lat) { 
double  deg  =  Math. floor (lat) ; 
double  min  =  (lat  -  deg)  *  60; 

String  out  = 

if  (deg  >  0) { 

out  =  String . format ( "N%02d  -  %#04f", (int)deg,  min); 


else  { 

out  =  "S"+  (int)deg  +  +  min; 

} 

return  out; 


public  static  String  LonToDegMin (double  Ion) { 
double  deg  =  Math . floor (Ion) ; 
double  min  =  (Ion  -  deg)  *  60; 

String  out  = 

if  (deg  >  0) { 

out  =  "E"+  (int)deg  +  +  min; 


else  { 

out  =  "W"+  (int)deg  +  +  min; 

} 


return  out; 

} 

} 

F.  WEB  SERVICE  DESCRIPTION  LANGUAGE  (WSDL) 

<?xml  version=" 1 . 0 "  encoding="UTF-8 "  standalone="yes"?> 

<def ini t ions  targetNamespace="http : //nav .uscg.mil/"  name="SearchPatternService 
xmlns : tns="http : //nav .uscg.mil/"  xmlns : xsd="http : //www . w3 . org/2001/XMLSchema" 
xmlns : soap="http : //schemas . xmlsoap . org/wsdl/soap/" 
xmlns="http : //schemas . xmlsoap . org/wsdl/"> 

<types> 

<xsd: schema> 

<xsd: import  namespace="http : //nav. uscg.mil/" 
schemaLocation="SearchPatternService_schemal . xsd"/> 

</xsd : schema> 

</types> 

<message  name="parallelSearchWS"> 

<part  name="parameters"  element="tns : parallelSearchWS" /> 

</message> 

<message  name= "paral lei Sear chWSResponse"> 

<part  name="parameters"  element="tns :parallelSearchWSResponse"/> 

</message> 

Cmessage  name= " sector Sear chWS"> 

<part  name="parameters"  element="tns : sectorSearchWS" /> 

</message> 

<message  name=" sector Sear chWSResponse"> 


118 


<part  name="parameters"  element="tns : sectorSearchWSResponse"/> 

</message> 

<message  name="squareSearchWS"> 

<part  name="parameters"  element="tns : squareSearchWS"/> 

</message> 

<message  name="squareSearchWSResponse"> 

<part  name="parameters"  element="tns : squareSearchWSResponse"/> 

</message> 

<portType  name="SearchPattern"> 

<operation  name= "par al lei Sear chWS"> 

<input  message="tns :parallelSearchWS"/> 

<output  message="tns : parallel Sear chWSResponse"/> 

</operation> 

<operation  name=" sector Sear chWS"> 

<input  message="tns : sectorSearchWS"/> 

<output  message="tns : sectorSearchWSResponse"/> 

</operation> 

<operation  name="squareSearchWS"> 

<input  message="tns : squareSearchWS"/> 

<output  message="tns : squareSearchWSResponse"/> 

</operation> 

</portType> 

<binding  name="SearchPatternPortBinding"  type="tns : SearchPattern"> 

<soap : binding  transport="http : // schemas . xml soap . org/ soap /http"  s tyle=" document " /> 
<operation  name= "par al lei Sear chWS"> 

<soap : operation  soapAction=" "/> 

<input> 

<soap:body  use="literal"/> 

</input> 

<output> 

<soap:body  use="literal"/> 

</output> 

</operation> 

<operation  name=" sector Sear chWS"> 

<soap : operation  soapAction=" " /> 

<input> 

<soap:body  use="literal"/> 

</input> 

<output> 

<soap:body  use="literal"/> 

</output> 

</operation> 

<operation  name="squareSearchWS"> 

<soap : operation  soapAction=" "/> 

<input> 

<soap:body  use="literal"/> 

</input> 

<output> 

<soap:body  use="literal"/> 

</output> 

</operation> 

</binding> 

<service  name="SearchPatternService"> 

<port  name="SearchPatternPort"  binding="tns : SearchPatternPortBinding"> 

<soap: address  location="REPLACE_WITH_ACTUAL_URL"/> 

</port> 

</ service! 

</definitions> 
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APPENDIX  D.  SEARCH  PATTERN  CLIENT  SOURCE  CODE 


A.  CODE  OVERVIEW 

This  code  provides  a  GUI  client  that  can  be  used  by  any  OS  that  supports 
the  Java  Virtual  Machine.  Swing  is  a  GUI  toolkit  for  Java.  It  is  one  part  of  the 
Java  Foundation  Classes.  Swing  includes  GUI  widgets  such  as  text  boxes, 
buttons,  split-panes,  and  tables.  This  client  is  one  way  to  consume  the  Search 
Pattern  Web  service. 


B.  SEARCH  PATTERN  SWING  CLIENT 


/* 

*  SearchForm. j ava 

* 

*  Created  on  November  27,  2006,  8:16  AM 
*/ 

package  mil . uscg . searchclient ; 

/  *  * 

★ 

*  @author  bob 
*/ 

public  class  SearchForm  extends  j avax . swing . JFrame  { 

/**  Creates  new  form  SearchForm  */ 
public  SearchForm ()  { 

initComponents ()  ; 

} 


/**  This  method  is  called  from  within  the  constructor  to 

*  initialize  the  form. 

*  WARNING:  Do  NOT  modify  this  code.  The  content  of  this  method  is 

*  always  regenerated  by  the  Form  Editor. 

*/ 

//  <editor-fold  defaultstate="collapsedn  desc="  Generated  Code  ">//GEN- 
BEGIN : initComponents 

private  void  initComponents ( )  { 

btnGrpSearchType  =  new  j avax . swing . ButtonGroup () ; 

jPanell  =  new  j avax . swing . JPanel () ; 

jRadParallel  =  new  j avax . swing . JRadioButton () ; 

jRadSector  =  new  j avax . swing . JRadioButton () ; 

jRadExpSq  =  new  j avax . swing . JRadioButton () ; 

jPanel2  =  new  j avax . swing . JPanel () ; 

jLblLat  =  new  j avax . swing . JLabel () ; 

jLabel2  =  new  j avax . swing . JLabel () ; 

jLblLen  =  new  j avax . swing . JLabel () ; 

jLblWidth  =  new  j avax . swing . JLabel () ; 

jLblTs  =  new  j avax . swing . JLabel () ; 

jLblMa  =  new  j avax . swing . JLabel () ; 

jTxtLat  =  new  j avax . swing . JTextField ()  ; 

jTxtLon  =  new  j avax . swing . JTextField () ; 

jTxtLen  =  new  j avax . swing . JTextField () ; 

jTxtWidth  =  new  j avax . swing . JTextField () ; 
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j TxtTs  =  new  j avax . swing . JTextField () ; 
jTxtMa  =  new  j avax . swing . JTextField ()  ; 
jPanel3  =  new  javax. swing. JPanel ()  ; 
jScrollPanel  =  new  j avax . swing . JScrollPane ()  ; 
j TxtAreaResults  =  new  j avax . swing . JTextArea () ; 
j ToggleButtonl  =  new  javax . swing. JToggleButton () ; 
j ToggleButton2  =  new  javax . swing. JToggleButton () ; 

setDef aultCloseOperation (javax. swing. WindowConstants ,EXIT_ON_CLOSE) ; 

j  Panel 1 . setBorder ( j  avax . swing . Border Factory . createTitledBorder ( "Search  Type" ) ) ; 

btnGrpSearchType . add ( jRadParallel) ; 

jRadParallel . setSelected (true) ; 

jRadParallel . setText ( "Parallel" ) ; 

jRadParallel . setBorder (javax . swing. BorderFactory . createEmptyBorder (0,  0,  0,  0) ) 
jRadParallel . setMargin (new  java. awt. Insets  (0,  0,  0,  0)  )  ; 
jRadParallel . addActionListener (new  j ava . awt . event .Act ionListener ( )  { 

public  void  actionPerf ormed ( j ava . awt . event .ActionEvent  evt)  { 
jRadParallelActionPerformed (evt) ; 


btnGrpSearchType . add ( jRadSector) ; 
jRadSector . setText ("Sector" ) ; 

jRadSector . setBorder (javax. swing. BorderFactory . createEmptyBorder (0,  0,  0,  0)  )  ; 
jRadSector . setMargin (new  j ava . awt . Insets  (0 ,  0,  0,  0) ) ; 
jRadSector . addActionListener (new  j  ava . awt . event .Act ionListener ( )  { 

public  void  actionPerf ormed ( j ava . awt . event .ActionEvent  evt)  { 
jRadSectorActionPerformed (evt) ; 


btnGrpSearchType . add ( jRadExpSq)  ; 
jRadExpSq. setText ( "Expanding  Square") ; 

jRadExpSq. setBorder (javax. swing. BorderFactory . createEmptyBorder (0,  0,  0,  0) ) ; 
jRadExpSq. setMargin (new  j ava . awt . Insets  (0 ,  0,  0,  0)  )  ; 
jRadExpSq. addActionListener (new  j  ava . awt . event .Act ionListener ( )  { 

public  void  actionPerf ormed ( j ava . awt . event .ActionEvent  evt)  { 
jRadExpSqActionPerformed (evt) ; 


org. j desktop . layout . GroupLayout  j PanellLayout  =  new 
org . j desktop . layout . GroupLayout (j Panel 1 )  ; 

jPanell . setLayout ( j PanellLayout) ; 
j  PanellLayout . setHorizontalGroup ( 

j  PanellLayout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 
. add (org. j desktop . layout . GroupLayout . TRAILING, 
j Pane 11 Layout . createSequentialGroup  ( ) 

.add  (34,  34,  34) 

. add (jRadParallel) 

. add ( 66 ,  66 ,  66 ) 

.  add  (jRadSector) 

.add (50,  50,  50) 

.add (jRadExpSq) 

. addContainerGap ( 35 ,  Short ,MAX_VALUE) ) 

)  ; 

j  PanellLayout . setVerticalGroup ( 

j  PanellLayout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 
. add (j  PanellLayout . createSequentialGroup ( ) 

.add (j  PanellLayout . createParallelGroup (org. j desktop . layout . GroupLayout .BASELINE) 

.  add  (jRadExpSq) 

.add (jRadSector) 

.add (jRadParallel)  ) 

. addContainerGap ( 8 ,  Short . MAX_VALUE) ) 

)  ; 


j  Panel 2 . setBorder ( j  avax . swing . BorderFactory . createTitledBorder ( "Search 
Parameters" ) ) ; 
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jLblLat . setText ("Latitude" )  ; 


jLabel2 . setText ("Longitude" ) ; 
j  LblLen . setText ( "Length" ) ; 
j  LblWidth . setText ( "Width" ) ; 
jLblTs . setText ( "Track  Space" ) ; 
j LblMa . setText ( "Maj or  Axis"); 

org. j desktop . layout . GroupLayout  j Panel2Layout  =  new 
org. j desktop . layout . GroupLayout (j Panel 2 )  ; 

j  Panel 2 . setLayout (j  Pane 12 Layout) ; 
j  Panel2Layout . setHorizontalGroup ( 

j  Panel 2 Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add (org. j desktop . layout . GroupLayout . TRAILING, 
j Panel 2 Layout . createSequentialGroup ( ) 

.add (j  Pane 12 Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add (jLblTs) 

.add (jLblLat) 

.add ( jLblLen) ) 

. addPreferredGap (org. j desktop . layout . Layout Style .RELATED) 

.add (j  Panel 2 Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

.add(jTxtTs,  org . j  desktop . layout . GroupLayout . DEFAULT'S I ZE,  93, 

Short . MAX_VALUE ) 

. add (j  Pane 12 Layout . createSequentialGroup ( ) 

. addPreferredGap (org. j desktop . layout . Layout Style .RELATED) 

.add ( jTxtLat,  org . j  desktop . layout . GroupLayout . DEFAULT'S I ZE,  93, 

Short . MAX_VALUE ) ) 

. add ( jTxtLen,  org . j  desktop . layout . GroupLayout . DEFAULT'S I ZE,  93, 

Short . MAX_VALUE ) ) 

. addPreferredGap (org. j desktop . layout . Layout Style .RELATED,  68 , 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

.add (j Pane 12 Layout . createParallelGroup (org. j desktop . layout . GroupLayout . TRAILING,  false) 
. add (org. j desktop . layout . GroupLayout . LEADING, 
j Panel 2 Layout . createSequentialGroup ( ) 

. addPreferredGap (org. j desktop . layout . Layout Style .RELATED) 

. add ( jLabel2 ,  org. j desktop . layout . GroupLayout . DEFAULT_SIZE,  78, 

Short . MAX_VALUE ) ) 

. add (org . j  desktop . layout . GroupLayout . LEADING,  j  LblWidth, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE,  7  8 ,  Short ,MAX_VALUE) 

. add (org. j desktop . layout . GroupLayout . LEADING,  j LblMa, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 

org . j desktop . layout . GroupLayout . DEFAULT_SIZE,  Short ,MAX_VALUE) ) 

. addPreferredGap (org. j desktop . layout . Layout Style .RELATED) 

.add (j Panel 2 Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING,  false) 

. add ( j TxtLon,  org. jdesktop . layout . GroupLayout . DEFAULT_SIZE,  93, 

Short . MAX_VALUE ) 

.add ( jTxtWidth) 

. add ( jTxtMa) ) 

. addContainerGap ( ) ) 

)  ; 

j  Panel2Layout . setVerticalGroup ( 

j  Panel 2 Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add (j  Panel 2 Layout . createSequentialGroup ( ) 

.add (j  Pane 12 Layout . createParallelGroup (org. j desktop . layout . GroupLayout .BASELINE) 

.add (jLblLat) 

. add ( j  TxtLat ,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 
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. add ( j  TxtLon,  org . j desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

.add ( jLabel2) ) 

.add (21,  21,  21) 

.add (j  Pane 12 Layout . createParallelGroup (org. j desktop . layout . GroupLayout .BASELINE) 

. add ( jLblLen) 

. add ( j  TxtLen,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. add ( j  TxtWidth,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

.add ( jLblWidth) ) 

.add  (2  6,  26,  26) 

.add (j  Panel 2 Layout . createParallelGroup (org. j desktop . layout . GroupLayout .BASELINE) 

. add ( jLblTs) 

. add ( j  TxtTs ,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. add ( j  TxtMa,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. add ( jLblMa) ) 

. addContainerGap ( 12 ,  Short ,MAX_VALUE) ) 

)  ; 


j  Panel 3 . setBorder ( javax . swing. Border Factor y . createTitledBorder ( "Results" ) ) ; 
jTxtAreaResults . setColumns (20) ; 
j  TxtAreaResults . setRows ( 5 ) ; 

j  Scroll Panel . setviewportview ( j  TxtAreaResults ) ; 

org. j desktop . layout . GroupLayout  j Panel3Layout  =  new 
org . j desktop . layout . GroupLayout (j  Panel 3) ; 

j  Panel 3 . setLayout ( j  Panel3Layout) ; 
j  Panel3Layout . setHorizontalGroup ( 

j  Panel3Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add ( j  Panel3Layout . createSequentialGroup  ( ) 

. addContainerGap ( ) 

. add (j  Scroll Panel ,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE,  396 , 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. addContainerGap ( 31 ,  Short ,MAX_VALUE) ) 

)  ; 

j  Panel3Layout . setVerticalGroup ( 

j  Panel3Layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add ( j  Panel3Layout . createSequentialGroup ( ) 

. add ( j  Scroll Panel ,  org . j  desktop . layout . GroupLayout . DEFAULT_SIZE,  227 , 

Short . MAX_VALUE ) 

. addContainerGap ( ) ) 

)  ; 

jToggleButtonl . setText ( "Generate" ) ; 

j ToggleButtonl . addActionListener (new  j ava . awt . event .Act ionListener ( )  { 

public  void  actionPerf ormed ( j ava . awt . event .ActionEvent  evt)  { 
j ToggleButtonlActionPerf ormed (evt) ; 

} 


jToggleButton2 . setText ( "Clear" ) ; 

j  ToggleButton2 . addActionListener (new  j  ava . awt . event .Act ionListener ( )  { 

public  void  actionPerf ormed ( j ava . awt . event .ActionEvent  evt)  { 
j ToggleButton2ActionPerf ormed (evt) ; 


org . j desktop . layout . GroupLayout  layout  =  new 
org. j desktop . layout . GroupLayout (getContentPane ( )  )  ; 
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getContentPane ( ) . setLayout (layout) ; 
layout . setHorizontalGroup ( 

layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add (layout . createSequentialGroup ( ) 

. addContainerGap  ( ) 

. add (layout . createParallelGroup (org. j desktop . layout . GroupLayout . LEADING) 

. add (org. j desktop . layout . GroupLayout . TRAILING, 
layout . createSequentialGroup ( ) 

. add ( j  ToggleButton2 ) 

. addPreferredGap (org. j desktop . layout . Layout Style .RELATED) 

. add ( j  ToggleButtonl ) ) 

.add (layout . createParallelGroup (org. j desktop . layout . GroupLayout . TRAILING,  false) 

. add (org. jdesktop . layout . GroupLayout . LEADING,  jPanel3,  0, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE,  Short . MAX_VALUE) 

. add (org. jdesktop . layout . GroupLayout . LEADING,  j  Panel 1 , 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 

org . j  desktop . layout . GroupLayout . DEFAULT_SIZE,  Short . MAX_VALUE) 

. add (org. jdesktop . layout . GroupLayout . LEADING,  j  Panel 2 , 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 

org . j desktop . layout . GroupLayout . DEFAULT_SIZE,  Short ,MAX_VALUE) ) ) 

. addContainerGap ( 20 ,  Short ,MAX_VALUE) ) 

)  ; 

layout . setVerticalGroup ( 

layout . createParallelGroup (org. jdesktop . layout . GroupLayout . LEADING) 

. add ( layout . createSequentialGroup ( ) 

. addContainerGap ( ) 

. add ( j  Panel 1 ,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE,  54 , 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. addPreferredGap (org. jdesktop . layout . Layout Style .RELATED) 

. add ( j  Pane 12 ,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE,  153 , 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. addPreferredGap (org. jdesktop . layout . Layout Style .RELATED) 

. add ( j  Panel 3 ,  org . j  desktop . layout . GroupLayout . PREFERRED_SIZE, 
org . j  desktop . layout . GroupLayout . DEFAULT_SIZE, 
org . j  desktop . layout . GroupLayout . PREFERRED_SIZE) 

. addPreferredGap (org. jdesktop . layout . Layout Style .RELATED,  13, 

Short . MAX_VALUE ) 

. add (layout . createParallelGroup (org. jdesktop . layout . GroupLayout .BASELINE) 
. add ( j  ToggleButtonl ) 

. add ( j  ToggleButton2 ) ) 

. addContainerGap ( ) ) 


pack  ( )  ; 

} / /  </editor-fold>/ /GEN-END : initComponents 

private  void  j ToggleButton2ActionPerf ormed ( j ava . awt . event .ActionEvent  evt)  {//GEN- 
FIRST:  event_j  ToggleButton2ActionPer formed 
//  Clear  Fields 
j  TxtLat . setText ( " " )  ; 
j  TxtLon . setText ( " " )  ; 
j  TxtWidth . setText ( " " ) ; 
j  TxtLen . setText ( " " )  ; 
j  TxtMa . setText ( " " ) ; 
j  TxtTs . setText  ( " " ) ; 
j  TxtAreaResults . setText ( " " ) ; 

} // GEN- LAST : event_j  ToggleButton2 Act ionPer formed 

private  void  j ToggleButtonlActionPerf ormed ( j ava . awt . event .ActionEvent  evt)  {//GEN- 
FIRST  : event_j  ToggleButtonlActionPerf ormed 
//  Get  Search  Results  from  WS 
double  lat  =  0; 
double  Ion  =  0; 
double  ma  =  0; 
double  width  =  0; 
double  length  =  0; 
double  ts  =  0; 
double  radius  =  0; 
double  theta  =  0; 
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double  crs  =  0; 
double  sqCount  =  0; 
int  i  =  0; 

lat  =  Double .valueOf (jTxtLat . getText ()) ; 

Ion  =  Double .valueOf (jTxtLon . getText ()) ; 

if  ( jRadParallel . isSelected ( ) ) { 

ma  =  Double .valueOf (jTxtMa . getText ()) ; 
width  =  Double . valueOf ( j TxtWidth . getText ()) ; 
length  =  Double . valueOf ( j TxtLen . getText ()) ; 
ts  =  Double .valueOf (jTxtTs . getText ()) ; 

try  {  //  Call  Web  Service  Operation 

me . searchclient . SearchPatternService  service  =  new 
me . searchclient . SearchPatternService  ( ) ; 

me . searchclient . SearchPattern  port  =  service . getSearchPatternPort () ; 

//  process  result  here 

j ava . lang . Ob j ect  result  =  port. parallelSearchWS (lat,  Ion,  length,  width, 

ma,  ts)  ; 

jTxtAreaResults . setText (result . toSt ring ( ) ) ; 

}  catch  (Exception  ex)  { 

//  display  exceptions  here 
jTxtAreaResults . setText (ex. toString ( ) )  ; 

} 

} 

if  (jRadSector . isSelected ()) { 

theta  =  Double .valueOf (j TxtWidth . getText ()) ; 
radius  =  Double .valueOf (j TxtLen . getText ()) ; 
crs  =  Double .valueOf (jTxtTs . getText ()) ; 
try  {  //  Call  Web  Service  Operation 

me . searchclient . SearchPatternService  service  =  new 
me . searchclient . SearchPatternService ( ) ; 

me . searchclient . SearchPattern  port  =  service . getSearchPatternPort () ; 

//  process  result  here 

java . lang. Object  result  =  port . sectorSearchWS (lat.  Ion,  theta,  radius, 

crs)  ; 

jTxtAreaResults . setText (result . toString ( ) ) ; 

}  catch  (Exception  ex)  { 

//  display  exceptions  here 
jTxtAreaResults . setText (ex. toString ( ) ) ; 

} 

} 

if  (jRadExpSq. isSelected ())  { 

crs  =  Double. valueOf (j TxtWidth . getText () ) ; 
sqCount  =  Double . valueOf ( j TxtLen . getText ()) ; 
ts  =  Double .valueOf (jTxtTs . getText ()) ; 
try  {  //  Call  Web  Service  Operation 

me . searchclient . SearchPatternService  service  =  new 
me . searchclient . SearchPatternService  ( ) ; 

me . searchclient . SearchPattern  port  =  service . getSearchPatternPort () ; 

//  process  result  here 

java . lang. Object  result  =  port . squareSearchWS (lat,  ion,  sqCount,  ts, 

crs)  ; 

jTxtAreaResults . setText (result . toString ( ) ) ; 

}  catch  (Exception  ex)  { 

//  display  exceptions  here 
jTxtAreaResults . setText (ex. toString ( ) )  ; 

} 
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} 

} // GEN- LAST : event_j  ToggleButton 1 Act ionPer formed 

private  void  jRadParallelActionPerf ormed ( j ava . awt . event .ActionEvent  evt)  {//GEN- 
FIRST:  event_j  RadParallelAct ionPer formed 

//  Setup  fields  for  Parallel  Search 
j  LblLen . setText ( "Length" ) ; 
j LblWidth . setText ( "Width" )  ; 
jLblTs . setText ( "Track  Space" ) ; 
jTxtMa . setvisible (true)  ; 
jLblMa . setvisible (true) ; 
jLblTs . setvisible (true)  ; 
j  TxtTs . setvisible (true) ; 

} //GEN-LAST : event_jRadParallelActionPerformed 

private  void  jRadExpSqActionPerf ormed ( j ava . awt . event .ActionEvent  evt)  {//GEN- 
FIRST:  event_j  RadExpSqActionPer formed 

//  Setup  fields  for  Expanding  Square  Search 

j LblLen . setText ("Cycles" ) ; 

j LblWidth. setText ( "Initial  Track" ) ; 

jLblTs . setText ( "Track  Space" ) ; 

j  TxtTs . setvisible (true)  ; 

jTxtMa . setvisible (false)  ; 

jLblMa . setvisible (false)  ; 

} //GEN-LAST : event_jRadExpSqActionPerformed 

private  void  jRadSectorActionPerf ormed ( j ava . awt . event .ActionEvent  evt)  {//GEN- 
FIRST  : event_j  RadSectorActionPerf ormed 

//  Setup  fields  for  Sector  Search 
j LblLen . setText ("Radius" ) ; 
j LblWidth. setText ( "Theta" ) ; 
jLblTs . setText ("Initial  Track" ) ; 
jTxtMa . setvisible (false)  ; 
jLblMa . setvisible (false)  ; 

} //GEN-LAST : event_jRadSectorActionPerformed 

/  *  * 

*  @param  args  the  command  line  arguments 
*/ 

public  static  void  main (String  args[])  { 

j ava . awt . EventQueue . invokeLater (new  Runnable ()  { 

public  void  run ( )  { 

new  SearchFormO  . setvisible (true) ; 


} 

//  Variables  declaration  -  do  not  modify//GEN-BEGIN: variables 

private  j avax . swing . ButtonGroup  btnGrpSearchType; 

private  j avax . swing . JLabel  jLabel2; 

private  j avax . swing . JLabel  jLblLat; 

private  j avax . swing . JLabel  j LblLen; 

private  j avax . swing . JLabel  jLblMa; 

private  j avax . swing . JLabel  jLblTs; 

private  j avax . swing . JLabel  j LblWidth; 

private  j avax . swing . JPanel  jPanell; 

private  j avax . swing . JPanel  jPanel2; 

private  j avax . swing . JPanel  jPanel3; 

private  j avax . swing . JRadioButton  jRadExpSq; 

private  j avax . swing . JRadioButton  jRadParallel; 

private  j avax . swing . JRadioButton  jRadSector; 

private  j avax . swing . JScrollPane  j ScrollPanel ; 

private  j avax . swing . JToggleButton  j ToggleButtonl ; 

private  j avax . swing . JToggleButton  j ToggleButton2 ; 

private  j avax . swing . JTextArea  jTxtAreaResults; 

private  j avax . swing . JTextField  jTxtLat; 

private  j avax . swing . JTextField  jTxtLen; 

private  j avax . swing . JTextField  jTxtLon; 
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private  j avax . swing . JTextField  jTxtMa; 
private  j avax . swing . JTextField  jTxtTs; 
private  j avax . swing . JTextField  jTxtWidth; 

//  End  of  variables  declaration//GEN-END: variables 
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